[luketheobscure]

> Do people not merge master into their branch before pushing? All that seems like mostly problem caused by having too long living branches.

On projects with a high commit velocity and a large team, simply merging main and running the tests is not enough. The likelihood that a new commit lands on main before your tests finish is high, and restarting the process every time there's a new commit is time consuming. Merge queues are the only way to ensure that main does not break from conflicts that arise "in between" commits.

[throwbadubadu]

> Do people not merge master into their branch before pushing?

No, they rebase! (Sorry, couldn't resist, yeah the other half does this (!attention, opinion!) ugly cross merges that make the commit graph look like my cables under the desk...

> Merge queues are the only way to ensure that main does not break from conflicts that arise "in between" commits.

Not the only one (though you may argue this is a degenerated queue): use merge locks! Yeah, we really use git svn style, the locking is done via a chat channel. No, please don't laugh. Acquire the lock, merge develop or rebase, check everything again, release lock :D :D (No again: I am not suggesting this to anyone!! :D )

[zizee]

The point the GP was making is that if merging to main is frequent (bigger team) and build times are long (bigger projects), catching your branch up to master before merging can be hard, as master is moving ahead faster than you rebase+build.

[throwbadubadu]

Fully understood.. we also have a big team, a too slow CI, and much too many LOCs. The "merge lock" will ensure you catch up, you keep the lock as long as it takes (or until others get too annoyed and urge you to step back) - as long as you have it nothing comes between you and main at the point you claimed it.

[Thorentis]

That sounds like an awful dev loop.

[ilyt]

Right but biggest projects out there like Linux kernel manage it just fine

> The likelihood that a new commit lands on main before your tests finish is high, and restarting the process every time there's a new commit is time consuming. Merge queues are the only way to ensure that main does not break from conflicts that arise "in between" commits.

But the code is still broken and still someone has to fix it ? That doesn't help in that.

As for "broken main", how is just not allowing code that doesn't pass tests to merge to main not enough ?

It all seems like a lot of complexity added because devs don't want to change shitty work practices...

[pperi11]

You could just use smaller PRs

See: https://graphite.dev/blog/the-ideal-pr-is-50-lines-long