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/