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
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/
Whether a merge commit was created was more-or-less random, depending more on the timing of the merge than on the relationship between the commits in Gerrit (which itself is transient - if you merge a commit on the bottom of the stack and then need to rebase the others, the relationship is lost). Consistently not having merge commits is an improvement IMO. It also makes a number of manual git operations easier.
On Mon, Jul 7, 2025 at 6:03 PM Lucas Werkmeister < lucas.werkmeister@wikimedia.de> wrote:
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.
Another downside to the linear Git history that I noticed today: `git branch -d review/[number]` is less likely to succeed, because the commit was probably rebased on merge, so it’s now a different commit even if the version I had previously downloaded with `git review -d [number]` was still the latest version.
Am Di., 8. Juli 2025 um 14:49 Uhr schrieb Gergo Tisza <gtisza@wikimedia.org
:
Whether a merge commit was created was more-or-less random, depending more on the timing of the merge than on the relationship between the commits in Gerrit (which itself is transient - if you merge a commit on the bottom of the stack and then need to rebase the others, the relationship is lost). Consistently not having merge commits is an improvement IMO. It also makes a number of manual git operations easier.
On Mon, Jul 7, 2025 at 6:03 PM Lucas Werkmeister < lucas.werkmeister@wikimedia.de> wrote:
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.
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/
On Wed, Jul 9, 2025 at 3:26 PM Lucas Werkmeister < lucas.werkmeister@wikimedia.de> wrote:
Another downside to the linear Git history that I noticed today: `git branch -d review/[number]` is less likely to succeed, because the commit was probably rebased on merge, so it’s now a different commit even if the version I had previously downloaded with `git review -d [number]` was still the latest version.
And not only the ones in that format, which implies that you are the person reviewing, but also local branches that you have pushed and are asking for review and got merged and you want to GC them in the local env.
For what it's worth, I 've been dealing with this consequence for the largest part of the last 12 years, since operations/puppet has been a rebase heavy repo for a very long time. Although this has been an explicit choice (with some back, forths and improvements over time), this is largely due to the nature of a Puppet codebase, given every change carries state. Overall, it's not as bad as it might appear. For the review/<thing> branch, you can do a git review -d to refresh them before deleting them, and overall a GC every once in a while where -D is used instead of -d fixes the issue. It's rare that you lose something, cause we all push to gerrit often enough.
Am Di., 8. Juli 2025 um 14:49 Uhr schrieb Gergo Tisza < gtisza@wikimedia.org>:
Whether a merge commit was created was more-or-less random, depending more on the timing of the merge than on the relationship between the commits in Gerrit (which itself is transient - if you merge a commit on the bottom of the stack and then need to rebase the others, the relationship is lost). Consistently not having merge commits is an improvement IMO. It also makes a number of manual git operations easier.
On Mon, Jul 7, 2025 at 6:03 PM Lucas Werkmeister < lucas.werkmeister@wikimedia.de> wrote:
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.
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/
-- Lucas Werkmeister (he/er) Software Engineer
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin Phone: +49 (0)30-577 11 62-0 https://wikimedia.de
Imagine a world in which every single human being can freely share in the sum of all knowledge. Help us to achieve our vision! https://spenden.wikimedia.de
Wikimedia Deutschland — Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Charlottenburg, VR 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207. _______________________________________________ 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/
Le 09/07/2025 à 16:13, Alexandros Kosiaris a écrit :
For what it's worth, I 've been dealing with this consequence for the largest part of the last 12 years, since operations/puppet has been a rebase heavy repo for a very long time. Although this has been an explicit choice (with some back, forths and improvements over time), this is largely due to the nature of a Puppet codebase, given every change carries state. Overall, it's not as bad as it might appear. For the review/<thing> branch, you can do a git review -d to refresh them before deleting them, and overall a GC every once in a while where -D is used instead of -d fixes the issue. It's rare that you lose something, cause we all push to gerrit often enough.
Hi Alexandros and Lucas,
The discussion about deleting local review branches that have been merged eventually has led me to implement a solution in git-review. I am using `git cherry` which compares the diff rather than the sha1. So if a change get rebased, the resulting commit will be detected has having been applied.
I have send the patch upstream https://review.opendev.org/c/opendev/git-review/+/955094:
List the status of local reviews branches: git-review --list-local
Test deletion: git-review --clean-local --dry-run
Delete them! git-review --clean-local
I could use some feedback on their Gerrit, here by email or on IRC :)
Antoine "hashar" Musso Wikimedia - Release Engineering
Le 09/07/2025 à 14:26, Lucas Werkmeister a écrit :
Another downside to the linear Git history that I noticed today: `git branch -d review/[number]` is less likely to succeed, because the commit was probably rebased on merge, so it’s now a different commit even if the version I had previously downloaded with `git review -d [number]` was still the latest version.
Hello,
I delete them without looking by forcing the deletion: `git branch -D`. That is because I consider them ephemeral and in almost any case I always refetch the change from Gerrit.
`git branch -d` checks whether the branch got merged, and with Gerrit rebasing a patch behind our hood, it get lost since the commit might have a different sha1 as the parent might be different.
There is another command that is used for email based workflow: *git cherry*. It compares the commits based on the diff and shows which commits have been applied and which one are yet to be applied
Assuming your:
* local branch `review/user/num` tracks a remote branch (which git-review -d should do) * the remote is up-to-date (git fetch origin / git fetch --all / git remote update)
Then when invoking `git cherry -v`, it compares the pending patches in your local branch with the remote and print them. The commits that have an equivalent in the remote branch are prefixed with a `-` (they have been merged), those that did not are prefixed with a `+`.
Example with integration/config, I had a local branch review/cmelo/T397271 which pointed to https://gerrit.wikimedia.org/r/c/integration/config/+/1163347/3. The branch is not fully merged:
git branch -d review/cmelo/T397271 error: The branch 'review/cmelo/T397271' is not fully merged.
But the patch has been applied:
$ git checkout review/cmelo/T397271 Switched to branch 'review/cmelo/T397271' Your branch and 'origin/master' have diverged, and have 1 and 74 different commits each, respectively. $ git cherry -v - 0c481434f44b95c354bbacf11258188e8b842f59 zuul: [mediawiki/extensions/CampaignEvents] add cldr as dependency
Or pull the branch and it is then deletable.
I am pretty sure git-review could be taught to automatically delete local review branches by using `git cherry` ;)
Antoine "hashar" Musso
wikitech-l@lists.wikimedia.org