On 06/06/2011 08:16 AM, Junio C Hamano wrote: > Scott Chacon <schacon@xxxxxxxxx> 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@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- 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