From: Johannes Schindelin Date: Tue, 23 Dec 2008 16:20:14 GMT Subject: Re: [PATCH] merge-recursive: mark rename/delete conflict as unmerged Message-ID: In-Reply-To: <7v7i5rhkix.fsf@gitster.siamese.dyndns.org> Hi, On Mon, 22 Dec 2008, Junio C Hamano wrote: > Johannes Schindelin 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. > 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