mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Randall S. Becker" <>
To: "'Kalyan Sriram'" <>,
	"'Junio C Hamano'" <>,
	"'brian m. carlson'" <>
Cc: <>
Subject: RE: Git submodule remove
Date: Fri, 22 Oct 2021 16:45:12 -0400	[thread overview]
Message-ID: <01a201d7c785$b9261ee0$2b725ca0$> (raw)
In-Reply-To: <>

On October 22, 2021 1:52 PM, Kalyan Sriram wrote:
>To: Randall S. Becker <>; 'Junio C Hamano' <>; 'brian m. carlson'
>Subject: RE: Git submodule remove
>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?

Given that git is distributed, probably not safer at all (see other responses in the thread). I really don't like the submodule rm concept in the slightest although I appreciate the necessity, but you really really have to want it. A prune operation might be better if a criteria could be specified to define when removing the submodule might be acceptable, at least locally. Suppose:

git submodule prune --branch=main --after=commitish

which could allow the prune if the submodule was not referenced on the main branches before a certain point in history. I don't like it, but it might be an idea worth thinking about.


  reply	other threads:[~2021-10-22 20:45 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
2021-10-22 20:45         ` Randall S. Becker [this message]
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 \
    --in-reply-to='01a201d7c785$b9261ee0$2b725ca0$' \ \ \ \ \ \

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