git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Git submodule remove

From
Junio C Hamano <gitster@pobox.com>
Date
Oct 22, 2021, 21:32 UTC
Message-ID
<xmqq8rykeoex.fsf@gitster.g>
In-Reply-To
<211022.86lf2ll00x.gmgdl@evledraar.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> 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.

Previous: Ævar Arnfjörð BjarmasonNext: Randall S. Becker
Message 11 of 15 in “Git submodule remove”
  1. Kalyan SriramOct 21, 2021
  2. brian m. carlsonOct 21, 2021
  3. Junio C HamanoOct 21, 2021
  4. Matheus TavaresOct 21, 2021
  5. Junio C HamanoOct 21, 2021
  6. Kalyan SriramOct 22, 2021
  7. Junio C HamanoOct 22, 2021
  8. Kalyan SriramOct 24, 2021
  9. Junio C HamanoOct 24, 2021
  10. Ævar Arnfjörð BjarmasonOct 22, 2021
  11. Junio C HamanoOct 22, 2021
  12. Randall S. BeckerOct 22, 2021
  13. Kalyan SriramOct 22, 2021
  14. Randall S. BeckerOct 22, 2021
  15. Junio C HamanoOct 22, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.