Handling file renames in git

Question

I'd read that when renaming files in git, you should commit any changes, perform your rename and then stage your renamed file. Git will recognise the file from the contents, rather than seeing it as a new untracked file, and keep the change history.

However, doing just this tonight I ended up reverting to git mv.

> $ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   index.html
#

Rename my stylesheet in Finder from iphone.css to mobile.css

> $ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   index.html
#
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   deleted:    css/iphone.css
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   css/mobile.css

So git now thinks I've deleted one CSS file, and added a new one. Not what I want, lets undo the rename and let git do the work.

> $ git reset HEAD .
Unstaged changes after reset:
M   css/iphone.css
M   index.html

Back to where I began.

> $ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   index.html
#

Lets use git mv instead.

> $ git mv css/iphone.css css/mobile.css
> $ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   renamed:    css/iphone.css -> css/mobile.css
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   index.html
#

Looks like we're good. So why didn't git recognise the rename the first time around when I used Finder?

Answer 1

you have to git add css/mobile.css the new file and git rm css/iphone.css, so git knows about it. then it will show the same output in git status

you can see it clearly in the status output (the new name of the file):

# Untracked files:
#   (use "git add <file>..." to include in what will be committed)

and (the old name):

# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)

i think behind the scenes git mv is nothing more than a wrapper script which does exactly that: delete the file from the index and add it under a different name

Answer 2

EDIT: I added Chris Johnsen's comment to my answer

For git mv the man page says:

The index is updated after successful completion, [....]

So, at first you have to update the index on your own (by using git add mobile.css). However git status will still show two different files:

$ git status
# On branch master
warning: LF will be replaced by CRLF in index.html
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   index.html
#       new file:   mobile.css
#
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       deleted:    iphone.css
#

You can get a different output by running git commit --dry-run -a which results in what you expect:

Tanascius@H181 /d/temp/blo (master)
$ git commit --dry-run -a
# On branch master
warning: LF will be replaced by CRLF in index.html
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   index.html
#       renamed:    iphone.css -> mobile.css
#

I can't tell you exactly, why we see these differences between git status and git commit --dry-run -a, but here is a hint from Linus

git really doesn't even care about the whole "rename detection" internally, and any commits you have done with renames are totally independent of the heuristics we then use to show the renames.

A dry-run uses the real renaming mechnisms, while a git status probably doesn't.

Answer 3

You didn't stage the results of your finder move. I believe if you did the move via Finder and then did git add css/mobile.css ; git rm css/iphone.css, git would compute the hash of the new file and only then realize that the hashes of the files match (and thus it's a rename).

Answer 4

Git will recognise the file from the contents, rather than seeing it as a new untracked file

That's where you went wrong.

It's only after you add the file, that git will recognize it from content.

Answer 5

How about the history for the old file?

Will this be copied to the new file(after rename), can we track the history of the old file to the new file.

Please let me know.

-Jee

Answer 6

@GregK

"I just moved a bunch of files into a public_html dir, that are tracked in git. Having performed git add . and git commit, it still showed a bunch of 'deleted' files in git status."

Sure. "git add ." tells git to copy any changes in files in the working copy to the index. It doesn't tell it to remove any files deleted from the working copy. You need an explicit "git rm" to do that. There's no "git mirror-working-copy-to-index" command, which seems to be what you were expecting "git add ." to do.