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@xxxxxxxxxxxxxxxxxxxx> > >Cc: Kalyan Sriram <kalyan@xxxxxxxxxxxxxxx>; git@xxxxxxxxxxxxxxx > >Subject: Re: Git submodule remove > > > >"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> 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
