git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Grimm <koreth@midwinter.com>
To: Nicolas Pitre <nico@cam.org>
Cc: John Goerzen <jgoerzen@complete.org>, git@vger.kernel.org
Subject: Re: Rename handling
Date: Mon, 19 Mar 2007 12:36:09 -0700	[thread overview]
Message-ID: <45FEE629.8030606@midwinter.com> (raw)
In-Reply-To: <alpine.LFD.0.83.0703191427140.18328@xanadu.home>

Nicolas Pitre wrote:
> Well...  the fact that you _still_ use GIT even in the face of a 1% 
> probability that it might guess renames wrong (according to your own 
> numbers) should mean that you didn't felt switching to Mercurial was 
> worth the 100% guarantee for rename identification.
>   

Yes, that's right, for me that's the correct tradeoff. For the person 
who asked the original question, it may or may not be. He seemed a lot 
more worried about the situation than I am. In my environment renames 
are relatively rare events, but maybe in his they happen more often.

> And some will argue that explicit renames are susceptible to user error 
> misidentifying the rename too, certainly in the 1% figure of all renames 
> if not more.
>   

If you're using "git mv" instead of "mv" to do the rename, it is 
impossible to misidentify the rename since the rename and identification 
are happening in the same command with no additional inputs that could 
confuse anything. If you are talking about adding a new tool that can 
manually tag a rename after the fact, then I can't disagree with you 
except to say that the fact that no such command exists today means any 
estimate of user error rate is pure speculation.

Aside from that, the possibility of user error is an entirely different 
thing than the possibility of tool error -- if I misidentify a rename, I 
will blame myself, not the version control system, and rightly so. 
People are expected to make mistakes from time to time. But if my 
version control tool misidentifies a rename on my behalf, and there's 
nothing I can do about it because there's no way to influence the tool's 
concept of what got renamed to what, then I'm not going to consider it a 
failure of the tool, not a mistake on my part.

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

-Steve

  parent reply	other threads:[~2007-03-19 19:36 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 [this message]
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
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=45FEE629.8030606@midwinter.com \
    --to=koreth@midwinter.com \
    --cc=git@vger.kernel.org \
    --cc=jgoerzen@complete.org \
    --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).