From: Jeff King <peff@peff.net>
Date: Thu, 09 Jun 2011 16:18:32 GMT
Subject: Re: Command-line interface thoughts
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:

> 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