Ittay Dror <ittayd@xxxxxxxxxx> writes: > Avery Pennarun wrote: > > Git already works fine for renames. The only situation where > > something funny happens is if you rename a whole directory and someone > > else creates a file in the old directory. (In that case, the new file > > ends up in the old place instead of the new place.) However, even in > > that case, there is still no conflict and no manual merging necessary. > > Sorry, but this is not the situation as I have experienced it with a > local repository I have. I renamed a directory (without changing any > files in it). 'git diff <commit>^ <commit>' shows the rename fine, but > 'git log -p -M -C <initial commit>..' does not (that is, the history > for files in that directory is shown from the rename commit > only). Obviously git-diff is not any better. This is one thing where git differs from other SCMs. In "git log -- <path>" (that is what I assume you have used) the <path> argument is path limiter. It allows to specify more than one directory or a file. Unfortunately currently "git log --follow=<file>" works only for single files, and doesn't yet work for directories; which is caused, among other things, by the lack of directory rename detection in git. > [...] Also, what happens if I change the file in the new location > and someone else changes it in the old location? Will I need to do a > manual merge? No, rename detection should make automatic merge possible. -- Jakub Narebski Poland ShadeHawk on #git -- 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
