I get frustrated when I browse a file from a git repository only to realize its history was lost due to improper renaming/moving of the file. It seems common for developers to manually rename/move a file in a git repository by using regular file system commands rather than git commands.
For example, let’s look at the following:
$ mkdir test $ cd test $ git init $ echo "hi" > test.txt $ git add test.txt $ git commit -m"add test.txt" $ mv test.txt test2.txt $ git status
So what have we here? We start off by creating a new directory called
test. We then go into the directory and start a new local git repository using
git init. Next we create a new file called
test.txt that contains simple text “hi”.
test.txt is then added and committed to the repository. Finally, we use the
mv command to rename the file to
git status shows us the result:
This is not what we were expecting. This shows that the original file
test.txt was deleted and now there is an untracked new file called
test2.txt, when it really should say that
test.txt was renamed to
Btw, this goes for moving files as well. For example, rather than renaming the file, if it was moved to, say, a different folder, e.g.
newFolder/test.txt, the result would be the same.
So how can this be solved? It’s actually not far off from the steps above. Let’s start with backtracking by reverting the rename:
$ git checkout test.txt $ rm test2.txt $ git mv test.txt test2.txt $ git status
Running the above commands produces the following result:
Much better, isn’t it? Renaming/moving files from git repositories the proper way will allow retention of their history, which is what we want.