From: Alex Riesen Date: Sat, 31 Mar 2007 17:34:45 GMT Subject: Re: [PATCH] Keep rename/rename conflicts of intermediate merges while doing recursive merge Message-ID: <20070331173445.GA7696@steel.home> In-Reply-To: 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 > > in the meantime. Signed-off-by: Alex Riesen > 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...