Re: Git submodule remove

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 22, 2021, 21:17 UTC
Message-ID: <xmqqlf2kep41.fsf@gitster.g>
In-Reply-To: <0101017ca921a6a0-96383fe2-4d73-47cb-83f7-4152b2c6ed7e-000000@us-west-2.amazonses.com>

"Kalyan Sriram" <kalyan@coderkalyan.com> writes:

Show 8 quoted lines

>> 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?

You MUST be able to go back to old versions. Otherwise, why are we working on a version control system? You may find that in the old days in v1.0 something used to work and in today's code it does not. You would want to bisect and need to be able to go back to v1.0 that still had the submodule you recently removed. And you check where in the history since v1.0 the actual breakage happend---it is called "bisection" and people do that all the time. IOW, it is VERY common.

And that is why I said "submodule rm" should *not* just "rm -fr submodule-dir/", but ensure that submodule-dir/.git is absorbed (in .git/modules/submodule-dir, most likely) before doing so, and then the entry for the submodule should be removed from .gitmodules, but I deliberatly did not mention anything about .git/config. The entry should in general _stay_ there, because having an entry for a submodule in .git/config means you are interested in it (e.g. your build may require having it, for a commit in the superproject that still had the submodule there). When you are on a commit in the superproject after the submodule was removed, you may not have anything from the submodule materialized in the working tree, but when you go back in the history, you do still need to be able to materialize it.

> In any case, this
> seems to be the project maintainer's problem, not git's.

You are correct. The remote side removing some repository and making it unavailable is just as bad as the site going down.

On your side, you would want to be able to continue working even when that happens, and not simply removing submodule-dir/.git together with submodule-dir/ before making sure the submodule is absorbed makes sure you'd have a local copy of the submodule repository available just like you have local copy of the superproject repository available.