Re: Git submodule remove

Ævar Arnfjörð Bjarmason [off-list ref] 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.