| 17 May 2024 |
 puck | In reply to @jade_:matrix.org
yeah, there were brief discussions on the forgejo channel about why we aren't using AGit on forgejo and my answer was just, it's not gerrit. it's totally fine that forgejo wants to be a gh clone, and we simply don't want that for reviews lol. tbh i haven't tried the agit flow yet; i might set up a test repo for it, but i suspect it's pretty much not good enough; but might eb a reasonable way to do gerrit-style PRs to the non-lix lix projects | 00:29:46 |
 jade_ | In reply to @puck:puck.moe
tbh i haven't tried the agit flow yet; i might set up a test repo for it, but i suspect it's pretty much not good enough; but might eb a reasonable way to do gerrit-style PRs to the non-lix lix projects it seems cute, but i think you can't push revisions with it? I'm not sure | 00:30:04 |
| puck | you can | 00:30:11 |
| jade_ | it doesn't support change-ids which makes me not willing to touch it | 00:30:14 |
| puck | but it's very underdocumented | 00:30:18 |
 Qyriad | tbh even if we had to specify the exact place to push instead of change IDs we'd be okay with that, but no per-commit history is a non-starter | 00:31:08 |
| puck | hence wanting to try it and document it | 00:31:08 |
 julia | one thing I don't understand about Gerrit, is if there's chsnge-ids, why bother adding merge commits to main for single-conmit-changes when you could just rebase ontop | 00:31:25 |
| jade_ | In reply to @julia:the-apothecary.club
one thing I don't understand about Gerrit, is if there's chsnge-ids, why bother adding merge commits to main for single-conmit-changes when you could just rebase ontop config setting | 00:31:34 |
| puck | this is a configuration thing we've like. not set | 00:31:36 |
| puck | We should, though. | 00:31:40 |
| jade_ | but the reason for it is that i understand that if you have a commit on top, it will lose the relation somehow | 00:31:55 |
| puck | hm? | 00:32:09 |
| jade_ | In reply to @puck:puck.moe
hm? i was looking into this in re Reviewed-On tags: https://groups.google.com/g/repo-discuss/c/1j_FkvlhM4M | 00:32:44 |
| Qyriad | I thought there was a setting like "merge commit if necessary" or somwthing | 00:32:50 |
| jade_ | yes | 00:32:56 |
| jade_ | that's what we have | 00:32:58 |
| Qyriad | ah | 00:33:02 |
| jade_ | i think that merges tend to result in git tooling behaving better, at very little disadvantage | 00:33:20 |
| jade_ | also it allows commit signing, which some people like | 00:33:28 |
| Qyriad | yeah we don't mind the merges personally | 00:34:21 |
| jade_ | https://gerrit-review.googlesource.com/Documentation/config-project-config.html#submit-type here we go | 00:34:30 |
| puck | i'd prefer not having them but not strongly | 00:34:30 |
| Qyriad | and often it ends up being a chain of at least a few commits | 00:34:34 |
| jade_ | the cherry-pick option is busted imo | 00:34:40 |
| Qyriad | rip | 00:34:45 |
| puck | i'd set it to rebase always | 00:35:03 |
| puck |
When rebasing the patchset, Gerrit automatically appends onto the end of the commit message a short summary of the change’s approvals, and a URL link back to the change in the web UI
| 00:35:25 |
| puck | ..if we want this in the history, hrm | 00:35:45 |
| jade_ | yeah that would be nice, but we could just fix forgejo to have links in that | 00:35:52 |
