1

I am using Kdiff3 as my mergetool for Git.

Upon running git mergetool, KDiff opens and a pop-up box shows up telling me :

  • Total number of conflicts : n
  • Number of conflicts solved automatically : a
  • Unresolved conflicts : n - a

At the top of the GUI there are 3 pairs of buttons : next/previous delta, next/previous conflict, next/previous unsolved conflict.

Can I navigate through the conflicts that were automatically solved for review ? When using "next/previous conflict" I can only navigate through the n - a unsolved conflicts.

It seems the conflicts that were solved automatically are not marked as conflicts at all anymore, but are demoted to deltas and are just lost with the rest of the deltas. That makes no sense to me.

Is my assessment correct ? How to allow for both automatic conflict-solving as well as navigation through them afterwards ?

Charles
  • 988
  • 1
  • 11
  • 28
  • Maybe I always have gotten simple merge conflicts. I usually just navigate through the automatically solved via the next/previous delta buttons for inspection. Isn't that not good enough for your case? As to the off-hand chance that the automatically solved conflicts need fixing, I think that's another topic altogether. I once manually fixed that and then used KDiff3. There's probably a better way to do that. – joeljpa Apr 05 '23 at 08:29
  • Suppose there are many deltas prior to any actual merging, and that only a small subset are actual conflicts upon merging. Then It will take me forever to navigate through all deltas looking for what were conflicts that were automatically solved by KDiff3. Also, the color code does not seem to inform me here, there is no red color (which is for conflicts) in the automatically solved conflicts, I think. Can someone confirm ? – Charles Apr 05 '23 at 08:35

1 Answers1

1

Your distinction between "conflicts that were solved automatically" and "deltas" is meaningless/does not exist.

There only exists "automatically resolved conflicts" and "not automatically resolved conflicts". And notice that due to different algorithms the set of changes that is put into each is different between plain git and KDiff3. KDiff3 is a bit more "aggressive" in what it accepts of close changes without giving up compared to plain git, although the difference has shrunken over the last couple of years, there used to be a greater difference.

Still it is not uncommon for git to mark something as a conflict it cannot resolve automatically, only for KDiff3 to declare that there are zero unresolved conflicts when started as difftool (or though my git-resolve-conflict-using-kdiff3 script).

So what is automatically resolved is not an exact science but rather heuristics that could and do change over time. And even when things are resolved automatically, this is only a guess on git's/KDiff3's part and there is absolutely no way of guaranteeing that the result is correct.

Consider the following merge conflict example:

Kdiff3 conflict screenshot

After manually correctly resolving the function signature to be static void hello(unsigned int count, const char *message), which was the only not automatically resolved conflicts, the result is still not correct because the function goodbye contains a call to hello which only has one argument and is not updated to contain the new count argument.

So you cannot rely on automatically resolved conflicts to be correct, no matter how much you wish it to be true. And yes it means that you should review all changes even if it "takes you forever".

Now you could do a couple of things that justifies doing a lighter/faster review inside KDiff3.

  • Review with git diff --cached (or possibly git diff -U10 --cached) after exiting KDiff3.
  • Run git test on all commits on the branch to verify the integrity/correctness, especially after a rebase.
hlovdal
  • 26,565
  • 10
  • 94
  • 165
  • So you are saying deltas are really conflicts that were resolved prior to my access to the GUI, wether by git or by kdiff. Then yeah, I definitely should always review all deltas. (though in your example, the compilation would fail, which is a good safeguard downstream of this). In that light, care to elaborate on your second suggestion ? I've never heard of `git test`. – Charles Apr 11 '23 at 14:57