Re: [PATCH] Keep rename/rename conflicts of intermediate merges while doing recursive merge

On Sat, 31 Mar 2007, Alex Riesen wrote:

No. It means that that particular rename/rename conflict has to be resolved *once*, since after that, the new merge will become the merge-base for future merges.

Now, that doesn't mean that you may not end up having that same conflict show up over and over again, because the new merge-base may (obviously) end up being a situation where the rename/rename conflict will continue to exist later on (because it conflicts with what the repo you pulled from will continue to have), but that's really no different from any other conflict..

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@linux-foundation.org>

in the meantime.

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

		Linus