On Wed, 8 June 2011, Michael Nahas wrote:
> On Wed, Jun 8, 2011 at 11:05 AM, Jeff King <peff@xxxxxxxx> 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@xxxxxxxxx> 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
--
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