Hacker News Reader

Comment by deathanatos | Hacker News Reader

We regularly¹ have unclean merges at my company, and I consider my coworkers competent, and well above "the bar". The biggest problem we have with clean merges is that nearly every CI system & code review tool out there doesn't test the final product — the merge commit — until after it is merged. GitHub follows this flow by default, and usually even with more CI tooling on the side. Something like bors-ng is what one has to adopt. (And we're struggling to do this for our monorepo due to other points the article touches on.)

While it is possible (if difficult) in git, some VCS systems struggle even harder with this: Perforce and derivatives, for example, simply can't, by design, perform atomic test & commit.

¹like once a month, or so, over the whole company

View on HN

This is my experience too. Traditional ci hygiene requires that the build runs clean on the developer machine before publishing a change. But once the build time crosses 10 minutes, people resent waiting and start to run test subsets, and count on the ci server to catch breakage. Once that becomes normal, breakage is inevitable. And if commit tempo is higher than a developer can finish a test-run, then it is impossible. Solutions include patch queues, pr builds, etc. but those are all more complicated than a single stream on head.

I haven't used github in a while, when does an unclean merge happen? When two people merge their branches at the same time?

Any two commits that conflict in a semantic sense (either change individually is okay, but both together don't work), but don't conflict in a syntactic sense (the changes are not textually near enough to each other to cause git to consider them conflicts, so an automatic merge can & will still happen; alternatively, they make the exact same change, and so don't conflict).

We see this often with lockfiles (someone updates a dep, someone else adds a new dependency; the merge is a new dependency to a version of the dependency that no longer exists), or version numbers that get incremented (each author increments once; the second merge, git will consider it the same add on both sides, and not a conflict, so the result it original_version+1, when it should be original_version+2).

Could this be fixed by using a better branching strategy?

merge into a stabilize branch and test that...

This would be a rose by a different name. So long as you're testing your branch's state, and not the end result of the merge — as most CI systems & GitHub end up pushing people towards — you're going to run into problems.

What makes testing the end result of the merge tricky, I suppose, is that it changes over time. (As other people merge into whatever "stabilize branch" you have, the result of merging your branch and the new HEAD of the stabilize branch must change.)

Reply on news.ycombinator.com