Re: [PATCH] modify/delete conflict resolution overwrites untracked file

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 10, 2008, 23:36 UTC
Message-ID: <7voczjy55g.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20081210211147.GA13624@localhost>

Clemens Buchacher <drizzd@aon.at> writes:

Show 22 quoted lines

> On Wed, Dec 10, 2008 at 12:51:59PM -0800, Junio C Hamano wrote:
>> Clemens Buchacher <drizzd@aon.at> writes:
>> 
>> > If it's a regression, it dates far back, since 1.5.0 fails as well.
>> 
>> A good lit(h)mus test to see if it is a regression or just a plain bug in
>> the recursive strategy would be to see what 'resolve' strategy does
>> (replace "merge" with "merge -s resolve" in your test).
>
> "merge -s resolve" fails with
>
> Trying really trivial in-index merge...
> error: Merge requires file-level merging
> Nope.
> Trying simple merge.
> Simple merge failed, trying Automatic merge.
> ERROR: c1.c: Not handling case ae9304576a6ec3419b231b2b9c8e33a06f97f9fb ->
> -> 8173b675dc61bb578b411c769c9fb654625a7c4e
> fatal: merge program failed
> Automatic merge failed; fix conflicts and then commit the result.
>
> and therefore passes the test.

Are you saying that:

 (1) the step should result in conflict and the merge should fail, but it
     should not clobber c1.c nevertheless; and

 (2) resolve fails to merge (as expected), and it does not clobber c1.c
     (as expected); therefore it passes the test.

If so, then you now established that it is a bug in merge-recursive, right [implementors of recursive-in-C CC'ed]?

Or are you saying that the step should not fail to begin with?