Clemens Buchacher <drizzd@xxxxxx> writes:
> On Wed, Dec 10, 2008 at 12:51:59PM -0800, Junio C Hamano wrote:
>> Clemens Buchacher <drizzd@xxxxxx> 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?
--
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
