What happens to a git submodule when its referenced repo is deleted?

Question

Suppose I find an interesting repository on github that I want to use, I add it as submodule and then one day the owner of the repo decide to delete the repo, would my submodule become broken?

Uppermost

To shorten jthill's answer: yes, they do become broken, but in an easily fixed way. :-) – Varian

Answer 1

You've still got the histories you already fetched, with submodule update or fetch or however you want to do it. You can still fetch those histories from any repo that has them, and push them wherever, it's the histories that matter, not which repo you or anyone keeps them in. The .gitmodules file is just notes on where to find them; when upstream deleted their repo those notes got outdated, but that's why git submodule init and git submodule update are separate commands: init loads your repo's config from the notes in .gitmodules and you can then change them as you like.

Parturifacient

What if i don't have local cache of the repo? Can I pull the submodule? – Uppermost

If you've ever updated the submodule, you've got all the history you need. git submodule update does a clone and/or fetch for you (and then a checkout or whatever you've configured, possibly by taking the defaults git submodule init set up from .gitmodules). When you git add a submodule commit, Git records the commit id in your committed tree. Git literally could not care less where that commit comes from, and in fact git submodule is a helper command, there to help you wrangle fetching the commits your history says it wants checked out there. That's all it's for. – Parturifacient

I mean that if I don't have local clone of any repo. I clone my repo, which has a submodule. If I call git submodule update, would I get all the files of the deleted repo from the stage before it was deleted? – Uppermost

Not if the url in .gitmodules isn't hosting that repo any more. If you can find an alternate source for the needed commits you can update your configs to point at the still-(or now-)valid url or path, and try it again. Many submodules' content isn't really optional, and I've taken to carrying non-optional submodule histories in the main repo. The helper command doesn't really have automation for that but the setup's easy, git submodule init and git worktree add. – Parturifacient

OK. So if I use a non-famous repository then it's unsafe to use it as submodule because if it's deleted then I cannot find any other people's copy to point to. Would you say that we should fork the repo for non-famous repository? – Uppermost

That'll work. How you get the needed commits is irrelevant to Git (or to the work), so long as you can get them. – Parturifacient

Answer 2

Short answer:

If you still have the cloned repository on your local, you will have access to all commit history of the deleted submodule up to your last clone.

If you re-clone your repository from GitHub, the content of the submodule will be lost, unfortunately.

In any case, if you can find another remote for the deleted submodule, for example, a fork on GitHub, or another clone on disk, you may be able to recover the deleted submodule from that remote.

---

If you are preparing against potential supply-chain disruptions caused by the removal of an upstream repository and wish to record all the history in your own GitHub repository then including the upstream as a git submodule alone is not enough.

Nodab