git gui: merge conflict display is misleading since it hides non-conflicting remote hunks

git gui: merge conflict display is misleading since it hides non-conflicting remote hunks

[Jon Seymour]

In v1.6.6.1 of git (cygwin build), git gui has behaviour that I
believe is misleading in the presence of merge conflicts.

In the case in point the file being merged had diverged from the base
in both the local and remote repos.

The main hunks in each change merged cleanly, but there was a trivial
conflict on one line.

In GIT gui this was rendered as:

   <<<<<<< HEAD
   +import someclass;
   =======
   >>>>>>> remote

GIT GUI did not render the the interesting hunk from the remote that
merged cleanly.

As a result, the user thinks that the only conflict is the import
statement, and elects to resolve the commit in favour of the local
commit. This is the wrong thing to do because the remote hunk is then
lost to the history.

On the other hand, if the user manually resolves the conflict with an
editor and then rescans, the resolution of the conflict is shown, but
the remote hunk is not shown. Only if the user then adds the resolved
file to the index, does the remote hunk display in GIT GUI.

In my view, the current behaviour of git gui when displaying merge
conflicts is misleading because the display falsely leads the user
into the mistaken believing that the only change in the remote is the
conflict when, in fact, this is not true.

Is there any good reason why GIT gui can't show the full diff between
the working tree file and the current HEAD?

jon.