Each git commit records the state of the source tree, and not whether there is a renaming (or something else) that created this state. So, if you just rename the file normally (and not with git mv ), the output of git status will be something like this:
# On branch master # 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: foo.txt # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # bar.txt no changes added to commit (use "git add" and/or "git commit -a")
If you then decide that you want to record the state of the tree with the renamed file, you can make this change with:
git rm foo.txt git add bar.txt
... then git status will show you:
# On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # renamed: foo.txt -> bar.txt
... and you can commit this with git commit , as usual:
git commit -m "Renamed foo.txt to bar.txt"
It is important to remember that when git tells you that the file was renamed when viewing the history, this is because it decided that the renaming must have happened by comparing the state of the tree with one version for another - this does not mean that the history was written rename operation.
Mark Longair Apr 05 2018-11-11T00: 00Z
source share