I think I’m not a fan of this :/ it seems like it will obscure the relationship between chains of changes? Maybe it’ll still be visible in Gerrit (I haven’t checked), but surely not in “pure” git (e.g. in the CLI) – there would just be one long stream of commits with no indication that some of these used to be stacked together.
Am Mo., 7. Juli 2025 um 10:40 Uhr schrieb Antoine Musso via Wikitech-l < wikitech-l@lists.wikimedia.org>:
Hello,
I have changed how Gerrit integrates changes which will eliminate the extra merge commits created by CI and ensure linear git history.
By default, when Gerrit submits a change it first attempt to fast forward the target branch. If it is not possible, it creates a merge commit and fast-forwards the branch to it. I have changed our configuration so that Gerrit will now rebase changes instead of generating those merge commits.
Thus when previously you would have an history with a merge commit:
- (master) Merge "Some nice feature" <jenkins-bot>
|\ | * Some nice feature <Jane Doe> |/
- The base branch <Ann Onymous>
With this change Gerrit I have made, Gerrit would now rebase the change. The history would now looks like:
- (master) Some nice feature <Jane Doe>
- The base branch <Ann Onymous>
This ensures our branches have a linear history, that would make it easier to follow.
Please let me know if you have any questions or encounter issues.
References:
- Gerrit submit strategy:
https://gerrit.wikimedia.org/r/Documentation/config-project-config.html#subm...
- Change default strategy to Rebase if Necessary:
https://phabricator.wikimedia.org/T390719
Antoine "hashar" Musso Wikimedia Release Engineering team
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/