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

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