> > Just out of curiosity: How does git handle the case where one file is > renamed differently in 2 branches and then the branches are repeatably > merged? I know that bzr handles this very well and in various tests I > did there were absolutely no repeated conflicts. Would git behave as > well in this scenario? > Ok - I got curious and decided to install git and try this myself. In this test I had a file hello.txt that got renamed to hello1.txt in one branch and hello2.txt in another. Then I merged the changes between the 2 branches. Here is how it looked after the merge in bzr: bzr status renamed: hello2.txt => hello1.txt conflicts: Path conflict: hello2.txt / hello1.txt pending merges: Nicholas Allen 2006-11-28 Renamed hello to hello1 and here's how it looked in git: git status # # Changed but not updated: # (use git-update-index to mark for commit) # # unmerged: hello.txt # unmerged: hello1.txt # unmerged: hello2.txt # modified: hello2.txt # nothing to commit So git is not telling me that I have a conflict due to the same file being renamed differently in 2 branches - well at least not in a way I can comprehend anyway! Whereas bzr made this very clear. Also, in git I ended up with 2 files: ls hello1.txt hello2.txt whereas in bzr there was only one file and I just had to decide which name it was to be given to resolve the conflict. I'm not sure how I should resolve the conflict in git but that's probably just because I am not familiar with it yet and the message it gave was not comprehensible or helpful to me in the slightest. In bzr it was very easy and repeatably merging caused no trouble at all - the name conflict had to be resolved only once. While it was good that git detected my file rename (although this was not hard as the contents did not change at all) the process in bzr was *much* smoother and more user friendly than it was it git. When you have conflicts I think it's especially important that the RCS inform you of what is really happening so you do not make mistakes. Bzr was much more informative than git was and told me exactly why there was a conflict and made it easy to resolve it. This situation is a pretty common one and it seems to me that git's content based approach is not as useful in this case as the file identity approach that bzr uses. Nick - 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