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

Clemens Buchacher [off-list ref] writes:

On Wed, Dec 10, 2008 at 12:51:59PM -0800, Junio C Hamano wrote:

quoted

Clemens Buchacher [off-list ref] writes:

quoted

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?

On Wed, Dec 10, 2008 at 03:36:11PM -0800, Junio C Hamano wrote:

Clemens Buchacher [off-list ref] writes:

quoted

"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.

The latter.

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

Correct.

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

No. IMO, merge should fail and abort. That is, it should not modify the
working tree at all and tell the user that an untracked file is in the way.

The tests check that merge returns an error code and c1.c is not modified.
Test number 5 fails, unless the merge strategy resolve is used. While this
indicates a bug in the recursive strategy, I am not satisfied with the error
output of the resolve strategy either. It should output

"error: Untracked working tree file '...' would be overwritten by merge."

just like test number 2 does.