Phil for Humanity Phil for Humanity
A Guide for the Survival of Humankind and Helping the World, Society, and Yourself.



Git Renamed Issue



A co-worker discovered an interesting bug in Git that I would like to share. Basically, Git status reports that a new file is a renamed file of an existing file.

Here is the most simple steps to illustrate this issue. First, assume that you have no changes in your Git repository, and assume there is a file called "test1.txt" already committed in your repository.

$ cp test1.txt test2.txt

$ date > test1.txt

$ git add test1.txt test2.txt

$ git status

On branch master
Your branch is up-to-date with 'origin/master'.

Changes to be committed:
  (use "git reset HEAD ..." to unstage)

        modified: text1.txt
        renamed: test1.txt -> text2.txt


Notice that the new file, that was a copy of the old file, appears to be old file renamed to the new file, while the old file has an independent change to it too. The new file does not need to be an exact copy of the old file either. This bug appears if the new file is very similar to another file in the repository that is also being modified. For instance, here is how creating a new file in the repository normally looks like.

$ cp test1.txt test2.txt

$git add test2.txt

$ git status

On branch master
Your branch is up-to-date with 'origin/master'.

Changes to be committed:
  (use "git reset HEAD ..." to unstage)

        new file: text2.txt


The good news is that Git does not store renaming of files in the commits, so you can safely ignore the renamed message without any ill effects. Alternatively, you can always separate the two changes of both files into two separate commits.

by Phil for Humanity
on 20150126

Related Articles
 » Git Status
 » The Price of Progress
 » Git Pull Deletes Script