On October 22, 2021 1:52 PM, Kalyan Sriram wrote: >To: Randall S. Becker <rsbecker@xxxxxxxxxxxxx>; 'Junio C Hamano' <gitster@xxxxxxxxx>; 'brian m. carlson' ><sandals@xxxxxxxxxxxxxxxxxxxx> >Cc: git@xxxxxxxxxxxxxxx >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@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? 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. -Randall
