Re: Unified merge driver pushed out to "master" branch

Fredrik Kuivinen <freku045@student.liu.se> writes:

> I am a bit confused about in what state the index should be in after a
> non-clean merge.

Yeah, I was confused when I wrote it.  Sorry.

> The way the 'resolve' strategy do this seems to be more usable than
> "leave unmerged entries in the cache". In particular, 'git diff' gives
> a usable output in this case.

You are certainly correct about what resolve does, and most
likely right what the most usable output is from an end user's
point of view.  While merging, there _could_ be cases where we
would want to take a look at the current head of our head or the
current head of their head, but my reasoning that leaving those
entries unmerged in the index file _might_ help that (which was
the reason behind that 'leave them unmerged' comment) was quite
faulty.  We can say 'git-diff-cache HEAD' and 'git-diff-cache
MERGE_HEAD' with and without --cached for that.  I think the
current 'resolve' behaviour is the most useful one.

> This is Tony Luck's test case, originally described in
> <200508232256.j7NMuR1q027892@agluck-lia64.sc.intel.com>.
>
> I reported the results for my algorithm on this case in
> <20050826184731.GA13629@c165.ib.student.liu.se>. I think that the
> result produced by my algorithm is the result which Tony expected to
> get.

Yeah, I agree.  I might have sounded as if I was saying that the
automated merge must match the actual result otherwise it is
buggy, but that was not what I wanted to say -- rather we might
have found cases where the traditional 'git-resolve' did a wrong
thing which slipped through unnoticed.


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html