Re: Git submodule remove

[Junio C Hamano <gitster@pobox.com>]

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

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