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, for
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 do
On Wed, Jul 9, 2025 at 3:26 PM Lucas Werkmeister <
lucas.werkmeis...@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 comm
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 la
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).
C
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 thes
