[tomthecreator]

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.

[tome]

> For anyone not using `merge.conflictStyle = diff3` I highly recommend trying it. It removes a lot of ambiguity when dealing with conflicting changes.

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

[vlovich123]

I use kdiff3 or bc4. I find those tools more powerful for fixing complicated merges and just as easy for simple ones (eg manual alignment for when the merge algorithm can’t recognize what is supposed to be aligned)

[actually_a_dog]

I’ve tripped over the exact scenario you mention in that post more than once. Usually, it’s not that I end up including an entire function that shouldn’t be there, though. I find it tends to be more like “Oh, here’s an extraneous bit of code that just showed up in the middle of this method. Hmmm....” Or, alternatively, I end up removing too much code, rather than too little.

[Myrmornis]

(plug) delta does special display of diff3 merge conflicts: https://github.com/dandavison/delta#merge-conflicts

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.

[actually_a_dog]

Yessssssssss! zdiff3 was by far the most exciting thing in the whole announcement for me. It’s a terrible feeling that comes over me when, not only do I get the pleasure of resolving a merge conflict, but I do it incorrectly, leading to a bad merge. Minimizing the amount of lines I have to consider when doing so seems like the most straightforward way to increase the accuracy of humans when resolving merge conflicts.

[rossmohax]

I wonder why they introduced new diff mode, rather than making diff3 better.

[steerablesafe]

It's semantically slightly different. In the case of diff3 if you remove everything but the base part, then you get exactly the base version, while in the case of zdiff3 you also get the prefix and suffix parts from the two branches that merge cleanly.

I guess the difference is subtle, especially that there can be other merges within the same file that merge cleanly in both cases.

[hmate9]

Some people are used it, prefer it and probably it would break some automated tests people have too.

[thombat]

Workflow: https://xkcd.com/1172/

[tester756]

who cares?

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

[junon]

> who cares?

Loads of people who have to maintain things.

[Minor49er]

This is a standard approach to software development: you introduce a new alternative for something that exists, then mark the existing inferior option as "deprecated". This gives developers a chance to learn about the new feature and move over to it by the time it actually gets removed in a future version. Cutting it immediately would cause a huge amount of frustration since the users of the feature would demand to know where it went or why it suddenly no longer works while the maintainers would have to scramble to find a solution. It would turn people off from using that software in the future.

[tester756]

The thing is that

>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"

[Minor49er]

I would argue that for most cases, that's preferable to simply cutting old functionality. The only exception would be in environments where the upgrade process is more rigid where users/admins know what's changing with an upgrade and have a safe and easy way to roll back in case of any issues.