Re: Command-line interface thoughts

[Jakub Narebski <jnareb@gmail.com>]

On Wed, 8 June 2011, Michael Nahas wrote:
> On Wed, Jun 8, 2011 at 11:05 AM, Jeff King <peff@peff.net> wrote:
>> On Wed, Jun 08, 2011 at 07:39:16AM -0400, Michael Nahas wrote:
>>
>>> On Wed, Jun 8, 2011 at 7:12 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>>>> I don't quite think that we need "git diff NEXT WTREE"; the short
>>>> and sweet "git diff" is short for a reason,
>>>
>>> To be clear, I'm not advocating and have never advocated getting rid
>>> of zero-argument "git diff".  I've advocated that every (whole
>>> project) diff command should be expressible by a "git diff TREE1
>>> TREE2".  I'm fine with defaults if one or zero trees are specified.
>>
>> I agree with this, but...
>>
>>> So "git diff" would default to "git diff NEXT WTREE".
>>
>> Isn't this going to be behavior change, since your NEXT is not quite the
>> same as the index? How do I now get an n-way combined diff of the
>> unmerged files in the index?
> 
> The index is a file in .git/ that serves many purposes.  NEXT is an
> image of the whole project.  NEXT can be computed from the index and
> HEAD.
> 
> During a conflicted merge, stage 0 of the index holds the resolved
> files.

It is simply not true.  During a conflicted merge, for conflicted files
there is _no_ stage 0!!!  Conflicted files have stage 1 == base, 2 == ours
and 3 == theirs, where those stages have all conflicts that can be resolved
automatically resolved, and places where there is conflict replaced by
merge-base ('base'), current branch into which we merge ('ours') and
merged branch ('theirs').

> WTREE holds all merge files: the resolved and the unresolved 
> (which have <<<< ==== >>>> blocks in them).

Worktree version has files with conflict merge markers added in place
where there is conflict.


> I propose that during a 
> conflicted merge, that NEXT be computed as HEAD plus the resolved 
> files, that is, the files in stage 0 of the index.

Why _HEAD_?
 
> "git diff HEAD NEXT" would print the resolved changes.
> "git diff NEXT WTREE" would print the unresolved changes
> "git diff HEAD WTREE" would print all changes.
> 
> I believe that is the same behaviour as "git diff", "git diff
> --cached" and "git diff HEAD" during a conflicted merge.

"git diff NEXT WTREE" would not behave (with your proposal) like
"git diff", but like "git diff --ours".

"git diff HEAD NEXT" would not behave like "git diff --cached"
(which shows only '*Unmerged path foo').

"git diff HEAD WTREE" would be the same as "git diff HEAD" (just
longer to write), only because it doesn't involve index at all.
 

> I do not know how "n-way" merge works.  I saw somewhere that indicated
> that it was a series of N-1 two-way merges.

Where this "n-way merge" came from?  Peff wrote about "n-way combined
diff", which is something different.

-- 
Jakub Narebski
Poland