On Thu, Jun 9, 2011, Michael Nahas wrote:
> On Thu, Jun 9, 2011 at 5:48 AM, Jakub Narebski <jnareb@xxxxxxxxx> wrote:
>> On Wed, 8 June 2011, Michael Nahas wrote:
>>> On Wed, Jun 8, 2011 at 11:05 AM, Jeff King <peff@xxxxxxxx> wrote:
>>>> Isn't this going to be behavior change, since your NEXT is not quite the
>>>> same as the index?
[...]
>>> 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_?
>
> Because we merged changed from another branch into HEAD.
> Or we pull changes from a remote branch into HEAD.
>
> When a commit is written, it will be part of the branch referenced
> by HEAD.
And by selecting HEAD for diff's NEXT you would have problems with rebase,
where you also can have conflicts, where 'ours' and 'theirs' are switched
around (at least from one point of view).
>>> "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.
"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". What I just realized that at least from what
you wrote (corner case!) in case of conflicts it would be different
from "git diff NEXT WTREE", as ours != HEAD.
[...]
>>> 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.
>
> N-way merge exists. It would be bad to say that I was answering a
> question about conflicted merges if I didn't produce an answer for
> N-way merges. Unfortunately, I don't have enough information about
> N-way merges to answer the question so I decided it was best to
> acknowledge my ignorance and that I was giving an incomplete answer.
Actually while git can do n-way merge (so called "octopus" merge), it
either resolves it cleanly, or refuses merge; it does not try to resolve
conflict and present conflicts in the index. So it is always "3-way
combined diff".
But you didn't answer about _combined diff_...
--
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