Git merge with KDiff3 : navigate through automatically solved conflicts for review?

Question

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 ?

Answer 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:

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.