Re: Command-line interface thoughts (ad-hominem attacks)

[Michael Nahas <mike.nahas@gmail.com>]

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?
>
> -Peff

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.  WTREE holds all merge files: the resolved and the unresolved
(which have <<<< ==== >>>> blocks in them).  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.

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

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.


Mike