Johannes Schindelin [off-list ref] 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.
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?
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