Re: Rename handling

[Steven Grimm <koreth@midwinter.com>]

Linus Torvalds wrote:
> It's much worse than that. I will *guarantee* that renames are missed when 
> they come in as traditional patches, for example. That's a 100% error rate 
> right there, not some "1%" one.
>   

That's an argument that the content-based rename detector is valuable 
and shouldn't be ditched, a sentiment with which I completely agree. It 
is a fabulous piece of work and handles cases that none of git's 
competitors get right, such as patches or tracking upstream 
distributions or tracking renames made by non-git-aware tools.

However, "Should we keep the existing rename detection?" is not the same 
question as, "Should the user be able to tell the system he's renaming 
something?" Or rather, given we already have git mv, "Should the system 
remember that the user has told it he's renaming something?" Right now 
git is throwing away metadata the user is feeding to it, metadata that 
could be used to eliminate the chance of a subsequent failure. As long 
as that metadata is used in *addition* to the existing logic, rather 
than as a *replacement*, the downside seems minimal. You won't have it 
in the case of a patch, granted, but that just means patches will use 
the existing, almost-always-right, rename detection, no harm done.

> So learn to love the bomb. Rename tracking is *wrong*. 
>   

Until someone comes up with a way to make content-based rename detection 
100% foolproof in the face of things like frequent self-references in 
Java or C++ classes, it may be a necessary evil (or at least a 
worthwhile one.)

-Steve