Hi, On Mon, 22 Dec 2008, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
