Why does git not ignore this particular __pycache__ directory?

INFORMATION

I made a commit today that failed:

git commit backend/projects/* -m "My message"
error: pathspec 'backend/projects/__pycache__' did not match any file(s) known to git

The commit included changes to files in subfolders that ALSO include their own __pycache__ directories, ie. I have a directory structure that looks like this:

backend/projects/__pycache__
backend/projects/my_altered_file_1.py
backend/projects/myfolder/__pycache__
backend/projects/myfolder/my_altered_file_2.py

In my .gitignore I have:

# Python byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]
*$py.class

And doing ls -al backend/projects/__pycache__ shows nothing but .pyc files in that directory, all of which match the *.py[cod] statement in .gitignore.

Doing:

git ls-files | xargs -n 1 dirname | uniq

gives me a list of the directories containing git-controlled files, which does NOT include the offending __pycache__ directory, so I know nothing in there has accidentally been added to git control previously (which would override the .gitignore).

QUESTION(S)

Why did the commit fail, when the contents of backend/projects/__pycache are completely .gitignored??

And why did retrying after deleting JUST the backend/projects/__pycache__ work fine, even though there's another __pycache__ directory in there which was ignored as expected (if it's going to fail on one, why wouldn't it fail on both)?

There is a fine print in git help commit (emphasis mine):

> DESCRIPTION
> [...]
> 3. by listing files as arguments to the commit command (without --interactive or --patch switch), in which case the commit will ignore changes staged in the index, and instead record the current content of the listed files (which must already be known to Git);

I don't know the exact reason why it is implemented that way, I guess that, since specifying a sequence of <path>... makes the commit include exactly these changes (ignoring the other possibly staged files), it makes sense to have an error when one of the files or directories listed on the command line will actually not be part of your commit.

As Richard Smith commented:
when you type git commit backend/projects/* -m "My message", the expansion is made by your shell, so git actually receives a command line which says :

git commit backend/projects/mymod1 backend/projects/mymod2 \
    backend/projects/myfile.py backend/projects/__pycache__ ...

The fix is to simply name the directory:

git commit backend/projects/ -m "My message"

Note that if you quote your glob string, the expansion will be done by git :

git commit "backend/projects/*" -m "My message"

this has however other consequences :
git will expand this glob to the list of files known to git under that directory, so new files under backend/projects/ would not be part of your commit.

I would recommend, however, to switch to a classical git add ...; git commit workflow, mainly because it allows you to :

git add ...
<review what you are about to commit>
git commit