Bad interaction between git clean, gitignore, and deleted submodules

Bad interaction between git clean, gitignore, and deleted submodules

[Craig Silverstein]

We have the following situation:
1) A .gitignore file that contains '*.pyc'
2) A repo with a submodule named jinja2

In normal use, clients of our repo have it checked out and run things
in it, creating files like jinja2/run.pyc.

I deleted the jinja2 submodule (by running `git rm jinja2` and
pushing).  Clients did a `git pull; git submodule update` and saw that
the jinja2 directory was still around, albeit untracked. So they ran
`git clean -ffd`.

The problem is that git clean refuses to delete the directory due to
the (ignored and thus uncleanable) file jinja2/run.pyc.  And when it
refuses to delete the directory, it also leaves around jinja2/.git.

Later, someone ran `git add .` and jinja2/.git got added back in as an
"orphaned submodule" (I forget the exact terminology).  I know there's
a very loud warning when this happens but somehow they didn't see it,
and it caused all sorts of trouble when they pushed their change.

My question: is it possible for a client to *really* get rid of the
jinja2 submodule?  We can't run `git clean -ffdx` because there are
other .gitignore'd files we want to keep around.

The behavior I'd like to see is for `git clean -ffd` to delete .git
files if they don't correspond to a currently registered submodule.
Then `git clean -ffd` would delete jinja2/.git even though it leaves
around jinja2/run.pyc.  But I don't know if that would break anything
else.

Or maybe we should just add `.git` to our `.gitignore`, so people who
run `git add .` can't create these orphaned submodules...

craig