git continues to control changes on __pycache__ even when it is in gitignore

Question

This is my .gitignore:

*__pycache__*
*.pyc
db.sqlite3
*.DS_Store
media/
res/

I can see on my Atom that __pycache__ directories are VcsIgnored (which implies that are recognized as not version controlled by git)

But, any way, when I make changes to a file, I get several __pycache__ files as modified and unstaged on my Atom git window:

I don't know wether the problem is in git or in Atom.

Answer 1

Try git rm --cached */__pycache__/*

.gitignore file only inform git which new files should not be tracked. Do not remove from repository files already tracked.

Answer 2

Updated to address follow-up questions in the comments

---

.gitignore only works on untracked files.

If paths show up as "modified" or "unstaged", that means the files are already tracked - they were in the index and probably in prior commits before you put them in gitignore, or they were force added after you put them in gitignore.

So you're trying to ignore modifications to tracked files, and that is not something you can do in git.

(To be clear, you will likely find answers saying that you can use various flags on the index to ignore changes to staged files. That almost always leads to trouble, because it's not what those flags are for.)

---

So how can you get these files ignored? You have to tell git to stop tracking them. This is easy to do, but it has potentially troublesome side effects.

Assuming you don't have a lot of long-lived branches, the simple approach is git rm --cached to unstage the changes, and then create a new commit. For example if you're only worried about cleaning up the master branch, you could

git checkout master
git rm -r --cached __pycache__ # or whatever other paths
git commit -m "remove unwanted files'

Now you should find that git status does not show these files by default, and git add does not add them. BUT, if you do something that changes the files and then

git checout HEAD^

moving back to a commit that had these files in it, git will quietly clobber the changes you had made to those files even though it doesn't have a copy of the changes from which to restore. And when you subsequently

git checkout master

they will be deleted from the worktree entirely.

For *.pyc files, maybe that's acceptable (since Python quickly/quietly regenerates them anyway); for other files it may not be, so this is at best a 'use with caution' approach.

An alternative - which avoids the above problems but comes with its own costs - is to rewrite history to look like the ignored files were never committed.

• Be aware that, as with any history rewrite, you would have to coordinate with anyone else that shares the repo

• If you decide to follow this path, there are existing questions/answers that document the procedure; you'd be looking for git-filter-branch with either a tree-filter or an index-filter.