| 17 May 2024 |
 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 |
| jade_ | change-ids can be linked | 00:35:57 |
| puck | (it'll add Reviewed-by, etc) | 00:36:03 |
| Qyriad | (which btw is also in refs/notes/, just not on the commit itself) | 00:36:41 |
| jade_ | i am confused why you can't have that behaviour on merge always | 00:37:02 |
| Qyriad | I guess just since it would then have put to that message in the merge commit and duplicate it for every commit in the merge? idk | 00:37:40 |
| puck | In reply to @jade_:matrix.org
i am confused why you can't have that behaviour on merge always mmm, we can check the source tomorrow | 00:38:05 |
 delroth | fwiw it doesn't add a merge commit if it doesn't need to, see e.g. my 2 commits on main: https://git.lix.systems/lix-project/lix/commits/branch/main | 00:39:32 |
| delroth | * fwiw it doesn't add a merge commit if it doesn't need to, see e.g. my 3 commits on main: https://git.lix.systems/lix-project/lix/commits/branch/main | 00:39:40 |
| Qyriad | okay yeah that's what we thought | 00:40:33 |
| jade_ | In reply to @qyriad:katesiria.org
I guess just since it would then have put to that message in the merge commit and duplicate it for every commit in the merge? idk mm right yeah ok that makes sense | 00:40:54 |
| Qyriad | we could just get in the habit of hitting the rebase button in gerrit more often. most of the time that even keeps reviews | 00:40:55 |
| puck | it probably merges if you have >1 commit | 00:42:24 |
| Qyriad | I think it is probably >1 commit submitted at the same time || commit's base is not HEAD | 00:42:52 |
 julia | you can have more than 1 commit with Gerrit? do I misunderstand how it works | 00:42:55 |
| Qyriad | you can have a relation chain! | 00:43:26 |
| julia | oh those can be merged all at once? | 00:43:44 |
| Qyriad | you can push a commit and that gets a change ID, and then push another commit on top which still gets reviewed separately, but can all be merged at once yep! | 00:44:00 |
| Qyriad | this is one of the best things about gerrit. you can be working on these huuuuuge changes that are still reviewable because they're split up logically and you can review each commit as it comes, but then still keep working on the later parts without blocking the whole thing | 00:45:35 |
| Qyriad | and then if it turns out that the later commits have some problems that will take more time, you can just merge the entire chain below and still have merged significant progress into the codebase | 00:46:19 |
| julia | :) | 00:46:33 |
