Re: Null deref in recursive merge in df73af5f667a479764d2b2195cb0cb60b0b89e3d

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jul 30, 2009, 08:00 UTC
Message-ID: <alpine.DEB.1.00.0907300958430.4589@intel-tinevez-2-302>
In-Reply-To: <7viqhaipg0.fsf@alter.siamese.dyndns.org>

Hi,

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

Show 18 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > 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