Sean Whitton <[email protected]> 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 ([email protected]) <https://www.eyrie.org/~eagle/>
