Re: [PATCH] merge-recursive: mark rename/delete conflict as unmerged

Hi,

On Mon, 22 Dec 2008, Junio C Hamano wrote:

Johannes Schindelin [off-list ref] writes:

quoted

When a file was renamed in one branch, but deleted in the other, one 
should expect the index to contain an unmerged entry, namely the 
target of the rename.  Make it so.

That was quick, but the surrounding code makes me wonder if other
if/elseif branches also need similar handling.

I tried to make sure that the surrounding code also adds unmerged entries, 
but I have to admit that my focus lay with the bug report at hand.

For example, rename/add comes up with a new name that does not exist 
anywhere, and adds both to the index; it is understandable that you need 
to do this when processing a merge with non-zero depth because you need 
to have a tree as the result, but shouldn't the final zero depth merge 
just use the original names and leave the results in higher stages?

Hmm.  I think this is a different issue (if you mean the issue that the 
result might be named differently than expected).

As for the unmerged entries, no, I do not think we need to do anything 
else besides calling update_file() and set try_merge = 1.

After all, if a file was renamed in one branch, but added directly in 
another, does it need to conflict?  I'd say no.

Ciao,
Dscho