On Wed, Dec 10, 2008 at 03:36:11PM -0800, Junio C Hamano wrote: > Clemens Buchacher <drizzd@xxxxxx> writes: > > > > "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. -- 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
