On Thu, Jun 09, 2011 at 11:06:56AM +0200, Michael Haggerty wrote: > My naive understanding is that in the case of a merge commit, the index > contains information equivalent to *multiple* trees: > > NEXT -- HEAD plus the files that have been resolved > BASE -- the contents of the common ancestor > OURS -- equivalent to the tree from HEAD > THEIRS -- equivalent to the tree from MERGE_HEAD Almost. Remember that as part of the merge resolution process, higher-level stages will collapse down to 0. So the "theirs" stage of the index is equivalent to MERGE_HEAD only if you have a conflict in every file and have resolved nothing. Otherwise, any resolved entries will not have a "theirs" entry at all. So when I do "git diff", we will see for resolved entries that the working tree matches stage 0 in the index, and show nothing. Whereas unresolved entries will have their diff shown. But with "git diff MERGE_HEAD", we will see differences from the other branch, even if those differences are simply resolutions or even changes made on the "ours" branch. So the index is not quite simply a set of four trees. The presence of various stages for each entry tells us the progress of resolution. -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