Does git rm remove all history of a file?
My project has a file
foo that I’ve been using and checking in with
git. I just did some refactoring so that I no longer need the file at all. If I do
git rm foo, will the file still exist in older commits? Will I be able to check out an older commit and work with the file?
3 Solutions collect form web for “Does git rm remove all history of a file?”
git rm (plus the commit) writes a new tree that reflects the file is no longer present. The entire history of the file, including creation, modifications, and eventual deletion, is present in the history.
git rm will only remove the file from the working directory and add that removal into the index. So only future commits are affected. All previous commits stay the same and the history will actually show when you removed the file from the repository.
In general all commits you made previously are permanent, so you should never need to worry about losing commits once they are somewhere in the history. Of course, there are some things that can remove or change previous commits (like rebasing), but for most things you do, you are pretty safe.
You will able to checkout any old version using known commit ID with all state belong to it, including files which are deleted now. See e.g. git branch <branchname> <start-point> where start-point is a commit ID. You even should not track that start-point belongs to the current branch; commit IDs shall be unique so it can be in any branch known to the current repository.
You can check previous history of the file using log command; but it works not in any syntax – for 1.7.7 I shall issue “git log — oldpath” instead of simple “git log oldpath” because otherwise it fails to distinguish path from revision. For some other commands as “blame” even this isn’t enough – one shall checkout old revision to start it.