Live data from Hacker News

The origin story of merge queues

mergify.com

31–34 of 34 posts

Re: The origin story of merge queues

#31
post #4

The Chromium commit queue slightly predates this -- they started using it in 2010.

(I work on a project that uses Chromium’s commit queue infrastructure)

I think there’s a big difference between Chromium’s approach and the “not rocket science” rule. AIUI Chromium’s model there are still postsubmits that must pass or a change will be reverted by a group monitoring the queue. This is a big difference in practice vs having a rotation or team that reorders the merge queue and rolls changes up to merge together. In the commit queue model you land faster at the expense of more likely reverts than in the merge queue model.

Re: The origin story of merge queues

#32
It’s a good idea and a deserved momentary rub-in-the-face blog post title back then to call it “not rocket science” (not for a decade+ name though).

I don’t use this because we just use the standard forge stuff. But yes, there shouldn’t be a reason to “break the build” and for small teams you shouldn’t need advanced tech to solve the issue (like for a bigger team with a large test suite it is tricky).[1]

But it would also be nice with some nice, readable history at the top level. Doesn’t have to be “curated” but you could have highlighted quotes and whatnot... I don’t know. Look at the Git project; the merge commits are decent.[2] The Rust project’s merge commits look like some dogfood factory ground floor where the coolers have malfunctioned. Bunch of weird command-like `r? @ghost rollup=...` which look like they were vacuumed up from GitHub via contributors or maybe also Tina Fey-bot. Then the commit message will the ill-suited MarkDown dump from the PR, including paragraphs with no hard-wrapping,[3] inline links (you can use reference style but okay), or how about some crazy ascii tables that look like a MySQL console[4] when you query a table with 20 columns (exaggeration). But I guess this is the not-rocket-science aesthetic of real serious business going on here.[5]

[1]: Shouldn’t need to buy some company software like whoever is selling this via their history lesson

[2]: A typical one would be “the frobinator in the config parsing segfaulted ..., which has been corrected”. Then with an inline subject-only “log” of all the commits. Pretty old-school.

[3]: The stuff they put in the commit message even uses an arrow to indicate “oh this was too long for me”: `feels like a regression as →` https://github.com/rust-lang/rust/pull/146121

[4]: 1ed3cd7030718935a5c5e5c8f6581f36d8be179f

[5]: Closer to the Linux Kernel style than the Git project, certainly

Re: The origin story of merge queues

#33

Despite the article, I'm not quite sure I understand exactly what this entails. Mainly I'm confused what this check is gating. Based on the article it's hard to tell what they mean. 1. Code changes that may conflict with each other in the repo, in the sense of a merge conflict. 2. Regressions (test failure, build breakage) caused by recently checked-in code. 3. Preparing and verifying a new release prior to deploymen…

Mergequeues generally solve (1), but not for git merge conflicts. It's for when the combination of two in-flight changes would result in a regression (aka "logical merge conflict" https://trunk.io/blog/what-is-a-logical-merge-conflict)

Re: The origin story of merge queues

#34
post #24
post #9

I don't know what it's like now, but GitHub's internal merge queue circa 2017 was a nightmare . Every PR required you to set aside a full day of babysitting to get it getting merged/deployed - there were too many nondeterministic steps. You'd join the queue, and then you'd have to wait for like 12 other people in front of you who would each spend up to a couple hours trying to get their merge branch to go green so it…

It got a little bit better, first with trains (bundling together PRs so they weren't going out one at a time), and then the merge queue started automating most of the testing and fitting together PRs into bundles that could go out together. But by the time I left GH last year it had devolved into roughly the same amount of hassle; I had multiple days where I could queue a PR for deploy mid-morning and not have the de…

How did you guys resolve merge or test conflicts? Did you just have to rebase, update your PR, and resubmit?
Post reply on HN