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?

  • Stash selected files with Git Extensions
  • How to maintain independence of pull request branches in the face of shared code
  • What is the difference between “py” and “pyc” in .gitignore notation?
  • Get gerrit patchsets via topic (for multiple repositories)
  • Merging Xcode project files
  • Change the position of the cursor in a git commit template
  • can't push upstream using EGit
  • Removing git submodules - how to automate removal on pull?
  • Discover which methods and classes were modified in a git commit?
  • How to refer to a previous commit in git commit message
  • How do you use “git --bare init” repository?
  • git repository sync between computers, when moving around?
  • 3 Solutions collect form web for “Does git rm remove all history of a file?”

    No, 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.

    No, 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.

    1. 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.

    2. 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.

    Git Baby is a git and github fan, let's start git clone.