RE: Git submodule remove

["Kalyan Sriram" <kalyan@coderkalyan.com>]

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 <sandals@crustytoothpaste.net>
> >Cc: Kalyan Sriram <kalyan@coderkalyan.com>; git@vger.kernel.org
> >Subject: Re: Git submodule remove
> >
> >"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 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?

Thanks!
Kalyan