Re: Rename handling

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Mar 19, 2007, 20:44 UTC
Message-ID: <Pine.LNX.4.64.0703191628100.6485@iabervon.org>
In-Reply-To: <45FEE629.8030606@midwinter.com>

On Mon, 19 Mar 2007, Steven Grimm wrote:

Show 5 quoted lines

> Nicolas Pitre wrote:
> > So maybe, just maybe, at the end of the day getting renames right 100% of
> > the time instead of 99% is not such a big thing after all.
> 
> For me personally, that is true -- but I'd still prefer that extra 1%.

I think the discussion of 99% is misleading here. The heuristics aren't random; it's not like if you do 2000 renames, you can expect 20 of them to be mishandled. What's actually going on is that git will get 100% on unambiguous cases; it'll get 100% on slight ambiguities; it'll get 100% on mostly clear cases. On the ~2% of cases where the correct result is arguable, git will choose differently from you half of the time. If you do a rename and have to change most of the lines of the file, git might decide that you rewrote it from scratch. On the other hand, you might have had an easier time rewriting it from scratch. Even more extreme, if you use git-mv to rename a file, and then you totally replace the file with some other content, git will treat it as a remove and an add, rather than a rename and a total rewrite. But making it a remove and an add is the sensible interpretation of the change, anyway.

I'd actually guess that git's analysis is at least as likely to be useful as the reference human analysis that the 1% error rate is measured against.

	-Daniel
*This .sig left intentionally blank*