Re: Gerrit and different merge UIs
- To: debian-devel@lists.debian.org
- Subject: Re: Gerrit and different merge UIs
- From: Russ Allbery <rra@debian.org>
- Date: Tue, 02 Sep 2025 10:48:46 -0700
- Message-id: <[🔎] 87h5xkvj7l.fsf@hope.eyrie.org>
- In-reply-to: <[🔎] 87ldmweqws.fsf@zephyr.silentflame.com> (Sean Whitton's message of "Tue, 02 Sep 2025 17:54:27 +0100")
- References: <81569BA4-9DAD-4A40-945B-7A918ED49E5A@debian.org> <5f37fb5a147ba5c4f75d94c5109d29e8@free.fr> <990a6d1b-0a67-48b8-b68b-45519f8391fb@debian.org> <CAOU6tACY+nXAGkGwbeg+hd_ZyhEA_KZxS6EHggASLRax8Mk=xQ@mail.gmail.com> <87ms81pw04.fsf@hope.eyrie.org> <aJ8Ij7Jkngsl_yU9@an3as.eu> <CAOU6tAAx2r7L6SQfCn5tZchimA6o539XqLv-9=MEaRZqCu96RA@mail.gmail.com> <87wm74r06t.fsf@hope.eyrie.org> <CAOU6tACeCsZOB0yHs93RkjqeXs69v=WhFC836DAfvV1yd-ryoQ@mail.gmail.com> <87frdsqbfh.fsf@hope.eyrie.org> <aKDFqt9t5UDabYWf@yuggoth.org> <87349r9hoi.fsf_-_@hope.eyrie.org> <CAOU6tABYjP+E-uK3zg071TyW=TUZAgv+SFqJC+W47Vd7iQ3fmw@mail.gmail.com> <[🔎] 87ldmweqws.fsf@zephyr.silentflame.com>
Sean Whitton <spwhitton@spwhitton.name> writes:
> On Sat 16 Aug 2025 at 02:08pm -07, Otto Kekäläinen wrote:
>> Hi,
>> ..
>>> fantastic for fire and forget changes to a bunch of packages. You can just
>>> make an MR and enable automerge, and not only will you be told if the
>> Yes, this feature is nice and is enabled by default. If you review a
>> MR and click "merge" before the CI passed, it will hold merging until
>> the CI actually passes.
> Modulo some very bad bugs:
> <https://gitlab.com/gitlab-org/gitlab/-/issues/429516>
> :(
There was some confusion after my original message between automerge and
merge queues (what GitLab calls merge trains), which I didn't bother
clarifying at the time because the thread was already too long. But for
the record I believe merge trains, if they're implemented the same as
GitHub's merge queues, would work around that bug, in addition to their
other benefits, if they were enforced on a repository.
(There are probably other more straightforward and obvious workarounds.)
Merge queues are not the same thing as automerge. Automerge just
automatically triggers a merge when the checks pass as if someone pressed
a button, but it doesn't coordinate or address races between multiple
merges. The two features are orthogonal on GitHub.
With merge queues (and presumably also merge trains), the exact MR as it
would be merged is separately tested on top of the current target branch
and is only merged if those tests pass. You can queue up multiple things
for merging and they're each tested one at a time in their merge order and
the merge is aborted if the exact state of the target branch after the
merge doesn't pass tests, thus avoiding all the cases where automerge can
merge an MR into a different state of the target branch than it was tested
against.
They're the most useful for repositories with a heavy and uncoordinated
merge load and help to flush out hidden semantic merge conflicts that
aren't obvious to Git.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: