Hello Emily, Monday, January 23, 2023, 11:12:32 PM, you wrote: ES> There is a little nuance here. Git can have nested repositories in a few different ways; submodules are just one of them. ES> A submodule is the combination of a gitlink object in the object graph *and* a corresponding entry in the .gitmodules file. ES> It's certainly possible to embed a nested repository in other ways, such as by ignoring the .gitmodules file, but then your ES> nested repository is no longer a submodule, and operations which recurse over submodules will not consider that nested repository. But it does consider. See the output of the `git submodule summary` command: https://github.com/gitextensions/gitextensions/discussions/10644#discussioncomment-4688533 ES> The reason is that we need to understand where to clone the submodule from - that information isn't contained in the superproject's ES> repository URL Yes, it does clone "externally", but after a clone it is contained in the `.git/config` of a subproject: [submodule] active = . [remote "origin"] url = ... ES> , and it can't be contained in the gitlink directly (which is in essence just a commit object, but one that exists ES> in the nested repository, not in the superproject repository). If we didn't have a way of writing down the submodule's remote URL ES> and version controlling it, we wouldn't have a way to populate the submodules when a user is cloning. The `git submodule summary` nevertheless can populate submodules after that, so this is not the matter. ES> The .gitmodules exists to help at clone time; it's possible, as I ES> think you're pointing out, to have some intermediate state locally. ES> But this file is what needs to be the source of truth for putting ES> together the repository on a new machine for the first time. Yes, the original clone command is superseded in those projects.
