From: Junio C Hamano <firstname.lastname@example.org>
To: "Ævar Arnfjörð Bjarmason" <email@example.com>
Cc: Matheus Tavares <firstname.lastname@example.org>,
"brian m. carlson" <email@example.com>,
Kalyan Sriram <firstname.lastname@example.org>, git <email@example.com>,
Emily Shaffer <firstname.lastname@example.org>
Subject: Re: Git submodule remove
Date: Fri, 22 Oct 2021 14:32:22 -0700 [thread overview]
Message-ID: <email@example.com> (raw)
In-Reply-To: <firstname.lastname@example.org> (=?utf-8?B?IsOG?= =?utf-8?B?dmFyIEFybmZqw7Zyw7A=?= Bjarmason"'s message of "Fri, 22 Oct 2021 14:12:11 +0200")
Ævar Arnfjörð Bjarmason <email@example.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
I know. That is exactly the layering violation I am unhappy about
but we came with it too far to remove.
next prev parent reply other threads:[~2021-10-22 21:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-21 17:25 Git submodule remove Kalyan Sriram
2021-10-21 21:36 ` brian m. carlson
2021-10-21 22:47 ` Junio C Hamano
2021-10-21 23:25 ` Matheus Tavares
2021-10-21 23:35 ` Junio C Hamano
2021-10-22 3:32 ` Kalyan Sriram
2021-10-22 22:02 ` Junio C Hamano
2021-10-24 20:33 ` Kalyan Sriram
2021-10-24 20:46 ` Junio C Hamano
2021-10-22 12:12 ` Ævar Arnfjörð Bjarmason
2021-10-22 21:32 ` Junio C Hamano [this message]
2021-10-22 13:47 ` Randall S. Becker
2021-10-22 17:52 ` Kalyan Sriram
2021-10-22 20:45 ` Randall S. Becker
2021-10-22 21:17 ` Junio C Hamano
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).