For anyone not using `merge.conflictStyle = diff3` I highly recommend trying it. It removes a lot of ambiguity when dealing with conflicting changes.
And now they introduced `zdiff3` which looks even better, will be trying it once I update.
And now they introduced `zdiff3` which looks even better, will be trying it once I update.
Yes, and to say that another way, it's literally impossible to resolve merge conflicts correctly with only the standard conflict style. See my post on StackOverflow for more details: https://stackoverflow.com/a/63739655/997606
It displays two diffs: one from the ancestral commit to “ours” and one from the ancestral commit to “theirs”. I find it helpful for understanding conflicts and how to resolve them — any feedback appreciated.
I hate this approach because this is very lazy (you avoid thinking about hard stuff and pick easy solution) and is very short term
sure you can introduce 150 configuration modes
but it makes your thing messy, confusing for new people, confusing for inexperienced and requires more maintenance
it's like taking tech debt
Loads of people who have to maintain things.
>by the time it actually gets removed in a future version.
doesn't always happen, so we're left with new, new v2, new v3 options and old one still exists "because it may break somebody's workflow"
I guess the difference is subtle, especially that there can be other merges within the same file that merge cleanly in both cases.