Re: Command-line interface thoughts

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Jun 9, 2011, 18:03 UTC
Message-ID: <4DF10ADA.5070206@alum.mit.edu>
In-Reply-To: <20110609161832.GB25885@sigill.intra.peff.net>

On 06/09/2011 06:18 PM, Jeff King wrote:

Show 15 quoted lines

> 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.

Thanks for the correction.  So one interesting pseudo-tree would be

OURS -- The NEXT version of any file that has been resolved; and the stage 2 version of any file that has not yet been resolved. The name seems consistent with what is meant by, e.g., "git checkout --ours".

Another interesting pseudo-tree would be

THEIRS -- The NEXT version of any file that has been resolved; and the stage 3 version of any file that has not yet been resolved. The name seems consistent with "git checkout --theirs".

The other trees HEAD and MERGE_HEAD are already accessible under those names, and so there is no need to make a special provision to access them.

BASE should presumably be something like the NEXT version of any file that has been resolved and the stage 1 version of any file that has not been resolved.

> 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.

Wouldn't the four trees described above contain information equivalent to the contents of the index? For example, the resolution work that remains to be done that can be inquired using old-fashioned "git diff" (3-way diff) could also be accessed via

    git diff NEXT OURS
    git diff NEXT THEIRS

or even

    git diff NEXT WTREE

if you want to see the remaining conflicts in <<<<<======>>>>>> format.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/