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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html