Re: Null deref in recursive merge in df73af5f667a479764d2b2195cb0cb60b0b89e3d

Hi,

On Thu, 30 Jul 2009, Junio C Hamano wrote:

Junio C Hamano [off-list ref] writes:

quoted

The codepath saw that one branch renamed dev-ubuntu/ stuff to dev/ at 
that "unmerged" path, while the other branch added something else to 
the same path, and decided to add that at an alternative path, and the 
intent of that is so that it can safely resolve the "renamed" side to 
its final destination.  The added update_file() call is about 
finishing that conflict resolution the code forgets to do.

By the way, (I am CC'ing Fredrik, the author of the merge-recursive.py,
the original implementation, even though I haven't seen him around here
for a long time. Two "thieves" are also CC'ed), I think the way recursive
strategy tries to handle rename/add and rename/rename conflicts by coming
up with a temporary pathname is fundamentally wrong.

If our branch (stage #2) added by renaming and their branch (stage #3)
added by creating the same path, why can't we simply leave these two
stages in unmerged state without funny "unique_path()" renaming?

AFAIR we could not leave the two in unmerged state because the "recursive" 
part of the recursive merge demands that we be able (at the intermediate 
merges) to write a tree.

But I agree that coming up with unique paths is wrong: if it is a 
rename/rename conflict, it should be

	<<<<<<<
	=======
	<file1>
	>>>>>>>

for one and

	<<<<<<<
	<file2>
	=======
	>>>>>>>

for the other rename target.

Ciao,
Dscho