Subject: Re: Command-line interface thoughts

From: Jakub Narebski <[email-masked]>
Date: Thu, 9 Jun 2011 15:06:30 +0200

Jakub Narebski wrote:
> On Thu, Jun 9, 2011, Michael Nahas wrote:
>> On Thu, Jun 9, 2011 at 5:48 AM, Jakub Narebski <[email-masked]> wrote:
>>> On Wed, 8 June 2011, Michael Nahas wrote:

[...]
>>>> "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".
>> 
>> OURS and HEAD are the same thing, so I doubt a command that does not
>> involve "HEAD" would behave like "--ours"
> 
> OURS and HEAD are not the same thing.  In OURS you have _conflicted_
> chunks replaced with HEAD ('ours') version, but chunks that can be
> resolved sutomatically are resolved; sometimes to 'theirs' version.

I'm very sorry, my mistake.  I have actually checked and OURS is the
same as HEAD version.

You wrote that NEXT contains either stage 0 for resolved files, or
OURS (HEAD) version for files with conflicts.  But that is exactly
what "git diff --ours" show.

> "git diff" in case of conflict prints 3-way combined diff between
> 'ours', 'theirs' and working area version.  As "git diff NEXT WTREE"
> doesn't print 3-way combined diff, it would be different for conflicts
> from "git diff".
> 
> "git diff --ours" for nonconflicted entry (stage 0 in index) would
> print ordinary diff between index and working area, just like
> "git diff NEXT WTREE". [...]

-- 
Jakub Narebski
Poland