Re: Command-line interface thoughts

[Michael Haggerty <mhagger@alum.mit.edu>]

On 06/06/2011 08:16 AM, Junio C Hamano wrote:
> Scott Chacon <schacon@gmail.com> writes:
>> For example, implementation details aside, I think having something
>> like WTREE and NEXT available would help users understand that there
>> are these 3 trees that are important and useful in Git and re-inforce
>> a very non-SVN style workflow in that manner.
> 
> That's a funny thing to say. Working tree may almost always (to put it
> another way, "you could make it to") act like a tree, but the index does
> not act like a tree at all in more important situations.

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

If my understanding is correct, then it would be logical to allow *any*
of these pseudo-trees to participate in a "git diff" during a conflicted
merge.

If I'm incorrect, then I expect a learning-experience-by-flame :-)

FWIW, when I was learning git, I struggled with exactly the problems
that Michael is trying to address.  My most frustrating moments always
involved trying to get my working tree and index from some existing
state to some desired state, because operations that seemed (in my
mental model) to be similar typically required using entirely different
git commands and/or command options.  Having a uniform nomenclature for
these concepts would be a big improvement (if the resulting abstraction
does not leak too badly).  I also think that the proposal for "git put"
would be a great help and would work nicely with the proposed changes to
"git diff".

Michael

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