From: Daniel Barkalow <barkalow@iabervon.org>
To: Steven Grimm <koreth@midwinter.com>
Cc: Nicolas Pitre <nico@cam.org>,
John Goerzen <jgoerzen@complete.org>,
git@vger.kernel.org
Subject: Re: Rename handling
Date: Mon, 19 Mar 2007 16:44:57 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0703191628100.6485@iabervon.org> (raw)
In-Reply-To: <45FEE629.8030606@midwinter.com>
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*
next prev parent reply other threads:[~2007-03-19 20:45 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-19 16:10 Rename handling John Goerzen
2007-03-19 18:14 ` Steven Grimm
2007-03-19 18:35 ` Nicolas Pitre
2007-03-19 18:48 ` Linus Torvalds
2007-03-19 19:57 ` Steven Grimm
2007-03-19 20:19 ` Martin Langhoff
2007-03-20 8:33 ` Junio C Hamano
2007-03-19 20:22 ` Linus Torvalds
2007-03-19 20:02 ` Robin Rosenberg
2007-03-19 20:34 ` Linus Torvalds
2007-03-19 19:36 ` Steven Grimm
2007-03-19 19:45 ` Steven Grimm
2007-03-19 20:07 ` Linus Torvalds
2007-03-19 20:17 ` Nicolas Pitre
2007-03-19 20:44 ` Daniel Barkalow [this message]
2007-03-19 19:03 ` Andy Parkins
2007-03-19 19:21 ` Steven Grimm
2007-03-21 0:06 ` Jakub Narebski
2007-03-21 0:25 ` Johannes Schindelin
2007-03-21 22:28 ` Steven Grimm
2007-03-21 23:01 ` Johannes Schindelin
2007-03-21 23:10 ` Linus Torvalds
2007-03-22 0:10 ` Martin Langhoff
2007-03-22 2:01 ` Jakub Narebski
2007-03-22 2:39 ` Martin Langhoff
2007-03-22 3:32 ` Jakub Narebski
2007-03-22 3:53 ` Linus Torvalds
2007-03-19 19:15 ` Daniel Barkalow
2007-03-19 19:49 ` John Goerzen
2007-03-19 22:27 ` Junio C Hamano
2007-03-21 0:21 ` Jakub Narebski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0703191628100.6485@iabervon.org \
--to=barkalow@iabervon.org \
--cc=git@vger.kernel.org \
--cc=jgoerzen@complete.org \
--cc=koreth@midwinter.com \
--cc=nico@cam.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).