RE: Git submodule remove

>To: Randall S. Becker <rsbecker@nexbridge.com>; 'Junio C Hamano' <gitster@pobox.com>; 'brian m. carlson'
><sandals@crustytoothpaste.net>
>Cc: git@vger.kernel.org
>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 <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?