[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)