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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Dec 23, 2008, 16:20 UTC
Message-ID: <alpine.DEB.1.00.0812231716000.30769@pacific.mpi-cbg.de>
In-Reply-To: <7v7i5rhkix.fsf@gitster.siamese.dyndns.org>

Hi,

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

Show 8 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > 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.

Show 5 quoted lines

> 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