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 - 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
