使用 ls 命令时，删除的文件夹仍然出现在 git bash 中

Question

For a C# project, I used git rm -r --cached obj/ and git rm -r -f obj/ command to remove obj/ from the directory, but after that when I used ls I could still see obj/ folder in the directory. When I tried to use git rm -r obj/ command again, it told me fatal: pathspec 'obj/' did not match any files , but I could still use cd obj/ to see all the files that were supposed to be deleted.

What does this mean?

Answer 1

git rm (without --cached ) should remove those files from the working tree (your disk) as well as the index, provided they were not ignored in the first place.

Check if:

• there was an ignore rule already in place

  git check-ignore -v obj/a_file_inside_obj

• if all files are still there, or only a few (which might not be deleted, because already used by an active thread)

Answer 2

Every file you use in Git has up to three simultaneously active copies. For concreteness, let's talk about the file named obj/a (I'll just assume there was such a file).

There is one copy of obj/a in three places when you start:

• One is—or might be, anyway—in the commit that you selected with git checkout master or git switch master or however it is that you selected a branch and therefore a commit.

• A second copy of obj/a in Git's index . The index, which is also called the staging area , holds a copy ¹ of each file ready to go into the next commit you will make. The copy in the index is first put there by your git checkout or git switch command. It stays there until you do something to or about it.

• Finally, the only copy of obj/a that you can see is an ordinary file in your work-tree or working tree .

The reason for the committed copy is that every commit holds a copy of all of your files, as the commit's snapshot. This copy, once made, can never be changed at all. No part of any commit can ever be altered: all commits are frozen for all time.

The reason for the work-tree copy is that the committed copy is not only frozen for all time, it's also compressed into a special Git-only format, that only Git can use. This is good for archival but useless for actually getting any work done. Git has to extract it and turn it back into a normal everyday file, so that you can use it. This is also why your work-tree is called "work-tree" or "working tree": it's where you do your work.

The index copy is the one that doesn't really have an obvious reason to exist. But Git has one. ²

When you ran:

git rm -r --cached obj/

Git removed the index copy of obj/a . The committed copy can't be removed: it's in a commit, and no part of any commit can ever be changed. The work-tree copy of obj/a , which is the one you can see and use, was left behind, because you told Git to leave it alone when you said --cached . So now you're down to two copies of the file, instead of three.

If you want to get rid of the work-tree copy of the file, use your computer's "remove a work-tree file" command, whatever that is ( rm , perhaps). Had you told Git earlier git rm -r obj/ you would have instructed Git to remove two copies: the one in the index, and the one in the work-tree. Now that the index copy is gone , git rm won't remove the work-tree one, because the work-tree copy is now an untracked file . So now you need to use the non-Git command.

(Alternatively, you could git add obj/a , which will copy the file into the index. Now it will be in all three places again, and now git rm obj/a will remove both the index and work-tree copies.)

---

¹ Technically, what's in the index is not an actual copy of the file, but rather the file's name and mode and a reference to the file's data, ready to be put into a new commit. But unless you start inspecting the index's content directly with git ls-files --stage , or using git update-index to change the index's content, the difference here is not all that important.

² That is, Git has a copy of the file there—although see footnote 1. Git has a reason, too: it makes it easier for Git to be Git. There are systems that work a lot like Git, but don't bother with an index. They just use the work-tree copy as the proposed next commit. That works, but it's slower and doesn't offer some of the features that Git does.

Answer 3

git rm just removes files from git. If you want to remove the files from the file system, you should use rm -rf ./obj .