Linus Torvalds, Sat, Mar 31, 2007 18:07:56 +0200: > > > > The result seem to be at least predictable. Still, doesn't it mean > > that once a rename/rename conflict is in it has to be resolved > > manually forever? > > The only way to resolve some conflicts in the long run is to either > - converge on some common case (ie normally by merging both ways > eventually, or just try to converge otherwise) > - remember the conflict resolution and re-doing it automatically (ie > "git rerere" for rename conflicts) > > That's very fundamental, btw. I don't think there *is* any other way to do > automatic merges in the long run, it has nothing to do with this > particular issue, it's a generic property of automatic merging. > > Junio - I think Alex' patch is better than what we have right now (which > is dying - whether with a SIGSEGV or a die() doesn't much matter), so it > should be applied. It probably isn't perfect, and I bet we can tweak the > resolution to something much better - Dscho seems to have ideas in that > areas. But: > > Acked-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> > > in the meantime. Signed-off-by: Alex Riesen <raa.lkml@xxxxxxxxx> > One thing we could/probably should do is to perhaps just add a flag about > "intermediate merges had complex issues", and refuse to commit the result > even if it looked "clean" in the end. It's better to make people perhaps > have to do an "unnecessary" extra git-commit, than to silently commit > something that might have been mis-merged. Just ask people to "please > verify the end result" kind of thing.. That'd be using the return value of inner merge which we historically do not do. Corresponding comment is in place: "The cleanness flag is ignored, it was never actually used, as result of merge_trees has always overwritten it: the committed conflicts were already resolved". Somehow it does not help to understand "why" the cleanliness of the inner merge does not matter... - 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