Re: blame follows renames, but log doesn't

[Steven Grimm <koreth@midwinter.com>]

Theodore Tso wrote:
> Actually, the bigger missing gap is merges.  Suppose in the
> development branch, you rename a whole bunch of files.  (For example,
> foo_super.c got moved to foo/super.c, foo_inode.c got moved to
> foo/inode.c, etc.)
>
> Now suppose there are fixes made in the stable branch, in the original
> foo_super.c and foo_inode.c files.  Ideally you would want to be able
> to pull those changes into the development branch, where the files
> have new names, and have the changes be applied to foo/super.c and
> foo/inode.c in the development branch.
>   

I believe git handles this case already, actually. I've seen this work 
just fine many times.

What git doesn't handle, but BitKeeper does, is applying directory 
renames to newly created files. I rename the "lib" directory to "util", 
you create a new file lib/strings.c and update lib/Makefile to compile 
it. I pull from you. Under BitKeeper, I will get util/strings.c and the 
change will be applied to my util/Makefile. git will create a brand-new 
"lib" directory containing nothing but the new file, but since the 
Makefile existed before, it will (correctly) apply your change to my 
util/Makefile, which will then break my build because it will refer to a 
file that doesn't exist in the Makefile's directory.

This has bitten me a few times in real life, e.g. in cases where I'm 
importing a third-party source tarfile and reorganizing it a little to 
fit it into my local build system. Every time they add a new source 
file, I have to go manually clean up after it rather than just merging 
the vendor branch into mine like I can do when they don't add anything. 
It is not frequent enough to be a major hassle for me but it sure is 
annoying when it happens (especially since sometimes the build *doesn't* 
break and it takes a while to notice a newly created file isn't where it 
should be.)

-Steve