Hacker News new | past | comments | ask | show | jobs | submit login
On the Nature of Merge Conflicts (neverworkintheory.org)
37 points by zdw on Aug 13, 2021 | hide | past | favorite | 6 comments



One way to help solve merge conflicts is incremental merge/rebase - bisect the merge to find which commit causes the conflict, then let the programmer solve that, then repeat again. I'm using git-imerge for this, but there is also mergify and a faster fork of it called git-mergify-rebase.

https://github.com/mhagger/git-imerge https://github.com/brooksdavis/mergify https://github.com/CTSRD-CHERI/git-mergify-rebase


Thank you for the links! I wrote my own crappier helper to "stitch" a conflicted branch back up to date with upstream. These are great.

Stitching together individual conflicted commits makes it obvious whether a conflict is purely textual or there's a true semantic conflict. I think a lot of programmers have a panic reaction to merge conflicts, don't think about what the conflict actually is, then introduce bugs through mistaken merges.


I definitely panic when encountering merge commits, then I remember imerge, abort the commit and work through each individual conflict with imerge. So much less stressful merging a very small conflict than a large one. Of course, this relies on your history splitting changes up into smaller more logical commits instead of mashing together giant commits with lots of unrelated changes.


> This was, to us, an unexpected result. Given all the commentary and folklore surrounding the merge problem and how difficult it is said to be to resolve merge conflicts…we had expected new code (NC) to be the most common choice.

Is this really particularly surprising? I've almost never written new code to solve a merge conflict. Merge conflicts are hard to resolve because they require making complex decisions, not because they require writing code.


I will go as far as to say that if you are repeatedly solving merge conflicts with new code you need to seriously revisit your version control choices. Merge conflicts are a tool to help you collaborate, they should not be an impediment.


I like the focus on tools to assist the human, rather than automating merge conflicts. Even if you come up with a new clever algo that reduces merge conflicts by x% from where we are now, how do you decide that these two pieces of now non-conflicting don't interact with eachother to produce undersirable behaviour? Unless you solve that pretty well, I much prefer the pattern of keeping a human brain in the loop.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: