Re: Rename handling

John Goerzen wrote:

If you commit your renames separately from your content changes, it'll be unambiguous and you won't have to worry about it. That's what I usually do when this is a concern and it has yet to break for me.

On the other hand, I agree with your general point; I really don't like being uncertain about whether renames are going to come out correctly or not ("it has always worked before" and "it is by design unable to fail" are two very different things.) In particular, I strongly disagree with the "names are just syntactic sugar, it's the content we're tracking" philosophy. Here's a simple example of why:

#include <xyz.h>

That simple statement is an intermingling of content and namespace. The presence of something like that actually breaks the "commit the rename separately" approach -- if you rename xyz.h to something else and commit just that rename, that revision won't compile, and I *really* don't like intentionally committing broken revisions.

Okay, so you say, rename xyz.h and update the references to it, but don't actually modify it. Fine, that works in this case. Now how about this one:

public abstract class Foo {
    private static Logger logger = Logger.getLogger(Foo.class.getName());
}

The references to the name "Foo.java" in that case are within the file itself (assuming you're using a Java compiler that requires the filename and class name to match, which the common ones do.) You can't change just the references without changing the file you're renaming. And, depending on how many self-references there are in this file, it's anyone's guess whether the content-based rename detection will consider the renamed file to be close enough to the old one to be a probable rename.

Combine renames with major code refactoring where the content changes substantially, and all bets are off.

Now, having said all that, I'll argue in favor of the content-based rename support for a moment. It is extremely cool that git will actually detect renames in third-party packages where you've just untarred a new release into your git repository and committed it, but have given git no hints at all about the nature of the content changes. I'm not aware of any other version control system that'll do that, and I've taken advantage of that feature in the past. So by no stretch am I saying that content-based rename detection is worthless.

But I would sure rest a lot easier if "git mv" would record a "the user renamed this file" entry in some log somewhere and the merge code would see that entry and say, "aha, no need to guess at it, file X got renamed to Y." Bonus points if that record could apply to directories too, so you don't have the "I created a new file in a directory you renamed, and after git-pull my file is still sitting by itself in the old directory" bug. If no such record exists, then the current rename code should still be invoked to work its considerable magic.

So to answer your question, in my opinion if 100% guaranteed renames are high on your priority list, then Mercurial might be the better option for now. In practice, I've found that git's 99+% rename detection has yet to fail on me aside from the above directory renaming case, but at the end of the day it *is* guessing at your renames after the fact.

Okay, git gurus, show me no mercy. :)

-Steve