[HN Gopher] On the Nature of Merge Conflicts ___________________________________________________________________ On the Nature of Merge Conflicts Author : zdw Score : 21 points Date : 2021-08-12 18:06 UTC (1 days ago) (HTM) web link (neverworkintheory.org) (TXT) w3m dump (neverworkintheory.org) | pabs3 wrote: | 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 | code_biologist wrote: | 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. | hazbot wrote: | 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. ___________________________________________________________________ (page generated 2021-08-13 23:00 UTC)