Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > Why would it be a good thing to change it even if we could? We added > that section with "git submodule add", it makes sense to have it removed > on "git init". ... on "git submodule rm", yes. Not "git rm". I am not sure what your "git init" is your typo for. That is primarily because I do not believe the "git submodule"'s world view is the _only_ valid porcelain UI for a feature that lets you use another project as if it is one of your subdirectories. So whatever opinionated policy the current "git submodule" implements, I'd prefer to keep it in "git submodule" (and ".gitmodules", which is where the data to support "git submodule"-style submodule handling lives in), not in the lower level "git add" and "git rm". > If anything I think it would make sense to extend this behavior. E.g. if > we "git rm" a <path> and notice that the <path> was the only thing that > matched a given entry in .gitignore we should remove that entry. I think that is a wrong analogy. It does not make sense to me to remove "*.o" from my .gitignore, when I do "git rm vendor-binary.o". I have "*.o" in .gitignore because I do not want to add .o files produced by compiling my source files, and the "git rm" does not change that fact at all. I unfortunately had to keep track of an opaque vendor-supplied binary, which got replaced recently with a new version, and that is why I am running "git rm" on it. "git add -f vendor-binary-v2.o" is what I was planning to do next. I do not want you to mess with my .gitignore; you are assuming too much on my workflow. > See 95c16418f03 (rm: delete .gitmodules entry of submodules removed from > the work tree, 2013-08-06) for the commit that gave "git rm" these > smarts. I know. That is exactly the layering violation I am unhappy about but we came with it too far to remove.
