Re: Command-line interface thoughts
- From
Jeff King <peff@peff.net>
- Date
- Jun 9, 2011, 16:18 UTC
- Message-ID
- <20110609161832.GB25885@sigill.intra.peff.net>
- In-Reply-To
- <4DF08D30.7070603@alum.mit.edu>
On Thu, Jun 09, 2011 at 11:06:56AM +0200, Michael Haggerty wrote:
Show 7 quoted lines
> 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