git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Parkins <andyparkins@gmail.com>
To: git@vger.kernel.org
Cc: Steven Grimm <koreth@midwinter.com>,
	John Goerzen <jgoerzen@complete.org>
Subject: Re: Rename handling
Date: Mon, 19 Mar 2007 19:03:17 +0000	[thread overview]
Message-ID: <200703191903.20005.andyparkins@gmail.com> (raw)
In-Reply-To: <45FED31B.8070307@midwinter.com>

On Monday 2007, March 19, Steven Grimm wrote:

> On the other hand, I agree with your general point; I really don't
> like being uncertain about whether renames are going to come out
> correctly or not ("it has always worked before" and "it is by design

I agree with you, but I think that git does exactly what you want.  In 
fact I think git is better.

The beauty of git figuring out renames for itself is that git can figure 
it out later. 

 $ mv file1 file2
 $ git update-index --remove file1
 $ git add file2

The important thing here is that git wasn't used to do the move.  This 
is great when you're lost in a development haze and do the move without 
thinking.

> So to answer your question, in my opinion if 100% guaranteed renames
> are high on your priority list, then Mercurial might be the better
> option for now. In practice, I've found that git's 99+% rename
> detection has yet to fail on me aside from the above directory
> renaming case, but at the end of the day it *is* guessing at your
> renames after the fact.

It's not really a guess; through the magic of sha-1, and provided you 
are disciplined enough to commit the rename without any changes to the 
content you can be sure that the rename is tracked.  The sha-1 /must/ 
be the same before and after.  For this 100% case, git doesn't even 
need the "-M", git-blame, git-diff and git-merge will find it anyway.

Even better is that because the rename isn't recorded explicitly when 
you upgrade git and the detection gets better, all your history 
instantly gets interpreted correctly.

The only command I've found that doesn't do the "right thing" by default 
is git-log and I think that once the following works, all the "why 
doesn't git track renames" people will go quietly away:

 $ git init
 $ date > file1
 $ git add file1
 $ git commit -m ""
 $ git mv file1 file2
 $ git commit -m ""
 $ git mv file2 file3
 $ git commit -m ""
 $ git log -- file3




Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

  parent reply	other threads:[~2007-03-19 19:06 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
2007-03-19 19:03   ` Andy Parkins [this message]
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=200703191903.20005.andyparkins@gmail.com \
    --to=andyparkins@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jgoerzen@complete.org \
    --cc=koreth@midwinter.com \
    /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).