git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Kalyan Sriram" <kalyan@coderkalyan.com>
To: "Junio C Hamano" <gitster@pobox.com>,
	"Matheus Tavares" <matheus.bernardino@usp.br>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
	"git" <git@vger.kernel.org>
Subject: Re: Git submodule remove
Date: Fri, 22 Oct 2021 03:32:12 +0000	[thread overview]
Message-ID: <0101017ca60e5ffd-9563fafd-86f6-443d-9cbe-e07203caacba-000000@us-west-2.amazonses.com> (raw)
In-Reply-To: <xmqqee8egddw.fsf@gitster.g>

On Thu Oct 21, 2021 at 4:35 PM PDT, Junio C Hamano wrote:
> Matheus Tavares <matheus.bernardino@usp.br> writes:
>
> > On Thu, Oct 21, 2021 at 7:47 PM Junio C Hamano <gitster@pobox.com> wrote:
> >>
> >> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> >>
> >> > On 2021-10-21 at 17:25:38, Kalyan Sriram wrote:
> >> >> Hello,
> >> >>
> >> >> I was curious why git-submodule does not have an `rm` command. Currently
> >> >> I have to manually delete it from .gitmodules, .git/config,
> >> >> .git/modules/, etc. See [0].
> >> >>
> > [...]
> >> I'd imagine that the happy-case implementation should be fairly
> >> straight-forward.  You would:
> >>
> >>  - ensure that the submodule is "absorbed" already;
> >>
> >>  - run "git rm -f" the submodule to remove the gitlink from the index
> >>    and remove the directory from the working tree; and
> >>
> >>  - remove the .gitmodules entry for the submodule.
> >
> > I think "git rm <submodule>" already does these three steps, doesn't it?

Wow, this is a surprise. Looks like this behavior is mentioned in the
man page but is not very well known.
> So perhaps "git submodule rm" would just become a synonym for "git rm"?
>
> Thanks.
Almost, yeah, but not quite. I ran a couple quick tests to clarify my own
understanding of how submodules work, and found that:

"git rm" deletes the submodule directory completely and modifies
.gitmodules, effectively removing the submodule. However, it leaves the
entry in .git/config dangling, which is annoying.

"git submodule deinit" (which I didn't know existed until I just read the man
page) deletes all contents of submodule directory, but leaves the 
(empty) submodule directory itself intact. It DOES delete the entry in
.git/config, but leaves a dangling entry in .gitmodules, so the next
"git submodule update --init --recursive" registers and populates the
submodule again.

>
> Wow, that is a unnerving layering violation, but I suspect it is too
> late to fix it. 
I agree, it's probably too late to change the behavior of "git rm"
regarding how it treats submodules. That said, I think the cleanest
solution would be to update "git rm" to also remove the dangling
.git/config entry. Then, I could make "git submodule rm" a synonym for
"git rm" for clarity. This would probably also involve updating
documentation in multiple locations to make sure everything is
consistent, and verifying "git rm" doesn't leave anything else about the
submodule dangling. Please let me know if anyone has a better idea for
anything I listed.

Thanks for your input so far, Junio, Matheus, and Brian! If no one has
any objections, I'll figure out how to make these updates and send a
patch along.

Thanks!
Kalyan

  reply	other threads:[~2021-10-22  3: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 [this message]
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
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

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  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 \
    --in-reply-to=0101017ca60e5ffd-9563fafd-86f6-443d-9cbe-e07203caacba-000000@us-west-2.amazonses.com \
    --to=kalyan@coderkalyan.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=matheus.bernardino@usp.br \
    --cc=sandals@crustytoothpaste.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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

	https://80x24.org/mirrors/git.git

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).