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 is very very slow when tracking large binary files
  • Stack Trace completely missing from rails server in git bash terminal for windows
  • Git pull into wrong branch
  • Why when I checkout a new branch using Git and push this new branch to origin repo, the base commit ID is 0000000000000000000000000000000000000000?
  • How to bridge to remote gits
  • git: finding which merge brough commit into the current branch
  • How to hide personal info from a publicly shared GitHub?
  • Can/should I fork my own github repo?
  • How to shrink Git repo and better manage large files
  • Repository deployment and Composer : what workflow?
  • Submodule at different branch
  • Managing a set of related repositories relative 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.