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