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?

  • git: How to rebase all commits by one certain author into a separate branch?
  • Do I need to publish to npm every time I update a package available via git?
  • What is the difference between pull and clone in git?
  • Yii2 installing extension from private git server - framework not see it
  • Git Hub Clone All Branches At Once
  • How do I swap the order of two parents of a Git commit?
  • Checkout (discard changes) on files with only whitespace/lineending changes
  • What does “*.jpg binary -delta” do in the .gitattributes file?
  • Is it possible to easily change the default conflict markers in Git?
  • What's the difference between SVN and Git for merging?
  • How to apply unmerged upstream pull requests from other forks into my fork?
  • How to view file history in Git?
  • 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.