git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Neal Kreitzinger <nkreitzinger@gmail.com>
To: nn6eumtr <nn6eumtr@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: How to deal with historic tar-balls
Date: Sat, 07 Jan 2012 13:18:45 -0600	[thread overview]
Message-ID: <4F089A95.9050300@gmail.com> (raw)
In-Reply-To: <4F079BA1.3060907@gmail.com>

On 1/6/2012 7:10 PM, nn6eumtr wrote:
> Thanks for the response, there is lots of good information there.
>
> One clarification - can you track renames in git? I tried using git mv 
> but from the status output it looks like it deleted the old file  and 
> added the new file. I was expecting it to record some sort of 
> indicator of the name change, instead it looks like a short-cut for 
> delete & add, the docs aren't clear if that is the case.
>
(note: top-posting is not advised.)
You are exactly right in your observation:  git-mv is only a shortcut 
for 'remove old then add new'.  Git does not explicitly track 
"renames".  It can detect renames easily in the cases where you really 
just renamed the file and left the contents the same.  Git tracks 
content (and trees) as opposed to files (and file names).  Git stores 
the 'blob', aka 'contents' of files in the object store.  So if you have 
30 files with different names and the exact same contents in your work 
tree they are stored as a single blob in the .git/objects "object 
store".  If some of your "renames" are really "I renamed it and then I 
modified it" then git will have a harder time detecting the "rename" 
depending on how much you modified it.  In such cases what you really 
did is arguably not a "rename" anyway.  You can record your "renames" 
manually in your commit message if appropriate.  If you have 5 minutes 
you can watch this video from the 15:00 min to 20:59 min marks to get an 
explanation of git-mv and rename-detection: 
http://www.youtube.com/watch?v=j45cs5_nY2k (youtube searchstring: 'git 
google tech talks', result: 'contributing with git'.)

v/r,
neal

      parent reply	other threads:[~2012-01-07 19:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-31 19:04 How to deal with historic tar-balls nn6eumtr
2012-01-01  0:27 ` Tomas Carnecky
2012-01-01 18:30   ` Philip Oakley
2012-01-01 20:54     ` Philip Oakley
2012-01-02 10:07     ` Philip Oakley
2012-01-02 18:26       ` Dirk Süsserott
2012-01-04 20:04         ` Philip Oakley
2012-01-01 19:04   ` Dirk Süsserott
2012-01-05 15:25 ` Neal Kreitzinger
2012-01-07  1:10   ` nn6eumtr
2012-01-07  1:50     ` Thomas Rast
2012-01-07 19:18     ` Neal Kreitzinger [this message]

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=4F089A95.9050300@gmail.com \
    --to=nkreitzinger@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=nn6eumtr@gmail.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).