mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Kalyan Sriram" <>
To: "Randall S. Becker" <>,
	"'Junio C Hamano'" <>,
	"'brian m. carlson'" <>
Cc: <>
Subject: RE: Git submodule remove
Date: Fri, 22 Oct 2021 17:52:07 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <016801d7c74b$64bb9a90$2e32cfb0$>

On Fri Oct 22, 2021 at 6:47 AM PDT, Randall S. Becker wrote:
> On October 21, 2021 6:47 PM, Junio C Hamano wrote:
> >To: brian m. carlson <>
> >Cc: Kalyan Sriram <>;
> >Subject: Re: Git submodule remove
> >
> >"brian m. carlson" <> 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 like to contribute my first patch to this project by adding this
> >>> feature, but wanted to check first with the community if there's any
> >>> particular reason it was chosen not to not be implemented, or if it's
> >>> simply that nobody has gotten around to it - it seems to be a
> >>> relatively common feature someone might want.
> >>>
> >>> Anyway, please let me know if this is something that would be
> >>> accepted, or if anyone has any comments or suggestions.
> >>
> >> I think the reason it hasn't been implemented is that nobody's gotten
> >> around to it yet.  I certainly would find this useful and have wanted
> >> the same thing myself, so I can't see a reason why the right series
> >> wouldn't be accepted.
> >
> >I tend to agree that nobody felt the need strongly enough.  Code tends to accumulate without ever getting removed, and removal of a
> file,
> >removal of a directory, or removal of a submodule is a much rarer event compared to other changes people would need to make.
> >Adding such a feature would have been much more work for those who faced such a rare occasion to want to use it than just doing it
> by
> >hand and committing the result.
> >
> >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.
> >
> >and you'd leave the final "record the state of the index as a commit" to the user, simply because the user would want to have other
> >changes related to the removal of the submodule in the same commit (like changes to files in the superproject that refer to the
> >submodule contents or removal of other submodules).
> >
> >The hard part is unhappy-cases.  There are too many things that can go wrong and you need to handle all the error cases correctly
> so that
> >you do not leave the user's repository in an uncontrollably messy state.
> Just my rambling:
> The really unhappy place is when a user deletes the upstream submodule
> repo itself after not seeing it in main any longer during
> some cleanup adventure, then someone else tries to check out an older
> commit that references the submodule.
IMO this seems like a pretty unlikely situation to be in, which doesn't
warrant *not* adding this feature. I get the idea, but how commonly do
people checkout old commits and play around with them? In any case, this
seems to be the project maintainer's problem, not git's.
> This particular unhappy
> place seems a whole lot like 'git branch -d' vs '-D', where it might be
> good not to allow the submodule rm if it is referenced in a
> commit (insert acceptable criteria for not forcing it here, which
> probably doesn't exist).
But wouldn't a submodule always be referenced in a commit? The first
thing anyone does after adding a submodule, after all, is to commit it
into the repository. Later on, you may decide you don't need that
submodule dependency anymore...
> A prune-like operation, as with workspace
> prune might be a little safer - but not much.
Sorry, I'm having a hard time understanding. What would this look like, and how
it would be safer?


  reply	other threads:[~2021-10-22 17:52 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
2021-10-22 13:47     ` Randall S. Becker
2021-10-22 17:52       ` Kalyan Sriram [this message]
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:

  List information:

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