| 17 May 2024 |
 julia | also emails: [PATCH 1/25] | 00:18:57 |
 Qyriad | In reply to @delroth:delroth.net
and then I think for 15s and realize that no, github actually really just sucks yeah like I couldn't really be sure that gerrit is any good at all or if it's just that github review is just that far below reasonable | 00:20:10 |
 jade_ | In reply to @delroth:delroth.net
and then I think for 15s and realize that no, github actually really just sucks 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. | 00:20:13 |
| jade_ | forgejo arguably fixes some serious deficiencies in github's review system like pr dependencies, but it's still PR shaped and you still can't get one-commit history | 00:20:51 |
| Qyriad | yup | 00:21:13 |
 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 |
