Steven Grimm wrote: > The following is actually my biggest beef with git's rename tracking, > and it has nothing whatsoever to do with git-log (though I agree git-log > needs to track renames too): > > $ ls > dir1 > $ ls dir1 > file1 file2 file3 > $ echo "#include file1" > dir1/file4 > $ git add dir1/file4 > $ git commit > $ git pull > $ ls > dir1 dir2 > $ ls dir1 > file4 > $ ls dir2 > file1 file2 file3 > > That's just plain broken in my opinion. One can perhaps contrive a test > case or two where that's the desired behavior, but in the real world it > is almost never what you actually want. > > By the way, I don't think fixing that is necessarily related to how > renames get detected, so in some sense it's a different bug report / > feature request than the rename hints one. It would be possible to > figure out the directory had been renamed based purely on content > analysis; a bunch of files all individually renamed to the same places > under a new directory, and a lack of any files at all left in the old > one, probably means the directory got renamed. The content-based rename > detector could handle this case. Actually this came out in some earlier talk about recording renames and renames detection (IIRC in the big thread about VCS comparison which used to be on Bazaar-NG wiki). And one of the arguments about why directory rename doesn't work as _you_ expected is (beside that it is not that easy to code) the fact that the alternate solution (new files going to old subdir) can be correct and expected by _others_. -- Jakub Narebski Warsaw, 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