On Tue, Feb 21, 2012 at 05:22:09PM -0600, Neal Kreitzinger wrote: > My definition for "auto-resolve": "During a merge, the working tree > files are updated to reflect the result of the merge... When both > sides made changes to different areas of the same file, git picks > both sides automatically, and leaves its up to you to make sure you > review those merge results for correctness after git has made the > merge commit." Once the merge commit is made, you can review these with: $ git show --raw which will give you the list of paths that were touched on both sides, and then you can examine them manually. You can also use: $ git show -c to get the combined diff, showing hunks that were changed on both sides (but only in files that would have been listed above). Annoyingly, I don't think there is a way to get the same multi-way diff information before the commit is created (i.e., when you still have some conflicts in the index and working tree left to resolve). But even both of those are not sufficient to find merge errors. Even though there is no textual conflict, there may be semantic conflicts that cross file boundaries (e.g., function foo() changes in foo.c, but a caller in bar.c is introduced on a side branch). There is no replacement for actually looking at the full result (though for the lazy, compiling and running the test suite can often catch the low-hanging fruit). -Peff -- 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