0

I have to delete few files and now they are showing in the Staging Area. How should I delete them permanently? I don't want to see them anywhere. I tried resetting the HEAD but all it does is brings back the files.

VS Code

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
Akshat Sharma
  • 23
  • 5
  • It seems you deleted the items on disk and then told Git to also delete them in the history. That's what is staged. If you commit now, the changes are transferred from the stage to the history and your stage is clear again. Do you want to modify the history as well? – Thomas Weller Apr 06 '21 at 06:45
  • you can use `git rm ` , this will delete the file from git and then use `git commit -m "msg"`, followed by `git push`. – Arindam Nayak Apr 06 '21 at 06:50
  • Thanks, It really helped, they are now permanently deleted from the system and not even showing on the stage. – Akshat Sharma Apr 06 '21 at 06:53
  • Nothing in "staging" is *permanent*. The staging area holds copies of files from commits: the copies *in* the commits can't be changed. Your working tree also holds copies of files from commits. The difference between the staging copy and the working-tree copy is that the staging copy is in Git's internal format, ready for the *next* `git commit` operation. – torek Apr 06 '21 at 07:11
  • 1
    What all this means is that the *staging copy* of every file becomes entirely irrelevant after a commit. The staging area is filled *from* a commit when you check out some commit. Check out some historical commit and the staging area is filled with the files from those commits, *even if they're deleted in later commits*. Check out the later commit again and the staging area has the older files removed and the newer files put in it, so the file that's *not* in the later commit is *not* in the staging area now. But you could put one back, so "in staging" is not *permanent*. – torek Apr 06 '21 at 07:13
  • The main thing to remember is that deleting a file, with `git rm`, means it won't be in the *next* commit. Until someone puts it back (if ever), it will continue not to be in these future commits. But it *still exists in past commits*. They cannot be changed. – torek Apr 06 '21 at 07:14
  • @torek Do you mean `work copy` instead of `stage`? If I checkout I don't modify the `stage/index` but the working copy – rioV8 Apr 06 '21 at 11:40
  • @rioV8: I really do mean staged copy here. You use `git add` to "modify" ("replace" is a better word, really) the staged copy of a file. If there was a copy from a commit, and you have changed the *working tree* copy and you want the updated file to be in the *next* commit, you must boot the current commit's copy of the file out of the staging slot and put in a new copy. Doing a checkout *also* replaces the staging copy. The staging copy is always ready for the *next* commit, and must be replaced if you've switched to some other commit ([caveat](https://stackoverflow.com/q/22053757/1256452)). – torek Apr 06 '21 at 13:56
  • @torek Aha, doing a checkout while there are staged files is not something I would do, what do you want to do with the changes staged, most likely keep them. So commit them or reset the staged and then the working copy. The link is some nice bed time reading, thanks – rioV8 Apr 06 '21 at 16:09

0 Answers0