6 ms·

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 t

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.

rossmohax 5y ago
I wonder why they introduced new diff mode, rather than making diff3 better.
- steerablesafe 5y ago
  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 5y ago
  Some people are used it, prefer it and probably it would break some automated tests people have too.
  - thombat 5y ago
    Workflow: https://xkcd.com/1172/ https://xkcd.com/1172/
  - tester756 5y ago
    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 5y ago
      > who cares? Loads of people who have to maintain things.
    - Minor49er 5y ago
      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 5y ago
        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 5y ago
        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.
tome 5y ago
> 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 https://stackoverflow.com/a/63739655/997606
- vlovich123 5y ago
  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 5y ago
  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.
actually_a_dog 5y ago
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.
Myrmornis 5y ago
(plug) delta does special display of diff3 merge conflicts: https://github.com/dandavison/delta#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.

rossmohax 5y ago

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

steerablesafe 5y ago
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 5y ago
Some people are used it, prefer it and probably it would break some automated tests people have too.
- thombat 5y ago
  Workflow: https://xkcd.com/1172/ https://xkcd.com/1172/
- tester756 5y ago
  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 5y ago
    > who cares? Loads of people who have to maintain things.
  - Minor49er 5y ago
    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 5y ago
      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 5y ago
        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.

tome 5y ago

> 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 https://stackoverflow.com/a/63739655/997606

vlovich123 5y ago
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 5y ago
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.

actually_a_dog 5y ago

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.

Myrmornis 5y ago

(plug) delta does special display of diff3 merge conflicts: https://github.com/dandavison/delta#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.