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
