Re: Rename handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 19 Mar 2007, Steven Grimm wrote:

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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]