: the one thing to look out for with "git diff" is that it will show up as empty if you've selected everything from one branch.
That's very much tied into how "git diff" really works (and it is true of the conflict diffs shown for merge commits after-the-fact too), and it is generally exactly what you want: if you've picked one side as the resolution to the conflict, the conflict is now "gone".
It does mean that if you incorrectly
picked one side of the conflict, and didn't really understand what the conflict was about, the conflict now becomes totally invisible to "git diff". So while the diff output is wonderful for merging, it does have the caveat that incorrect merges can become very hard to notice, because there is absolutely no sign of them left.
The reason I mention this is because I suspect the "empty git diff" thing tends to sometimes lull people into a false sense of security: "the conflict is gone".
So after a particularly subtle merge, I often look at several diffs:
- The plain "git diff <filename>" (before doing a "git add" to finalize the resolution) shows very nicely how the same area picked parts from both sides.
- Doing a "git diff HEAD <filename>" and "git diff MERGE_HEAD <filename>" then shows how the different "sides" of the merge got modified by the merge.
Also, note that while "gitk --merge" is really useful, it is
limited to showing the changes at a file boundary. And while that is usually what you want, sometimes it means that you may have tons of changes to that particular file that simply aren't relevant to the particular merge conflict. Using the "search" thing in gitk does help ("Ok, that commit doesn't modify anything around the conflict"), but it can sometimes be easier to just use the normal text-format "git log -p" model to more easily look for the changes that are relevant to the particular conflict (and search within 'less' for the code that conflicts).
The same arguments that work for "gitk" work for "git log" too, so you can do "git log -p --merge <pathname>". And with "git log" you can also then use arguments like "--grep" or "-S" to limit the commits you even see (--grep greps the commit message, and -S is useful if you have a particular string that you know changed in both branches: you can then use -S to show only the commits in which that string was introduced or removed).