Bug: Git - Submodules are not processed when cloning a git project. (issue # 227150)

[rerdavies]

I would like to file a follow-on to issue # - 227150. Members of the public aren't able to re-open closed issues. So I would be grateful if you would either re-open the original issue, or open a new issue -- whichever best fits your process. And edit the issue references as appropriate (either actual links, or not actual links).

With regards to the implementation of issue #227150 , now in the insider release,...

At the risk of sounding ungrateful, I have to ask.....

The Recursive clone should be the default behavior, not a second button. Perhaps there should be a "Recursive" checkbox that defaults to true, but I don't think so. The correct implementation is to make the existing button do recursive clones. A defense of this statement follows.

One has to ask: is there actually a use-case where anyone would EVER want to non-recursively clone a git repository. If you were to reverse the buttons ( Clone, and Clone Non-Recursively), would anyone EVER click on the second button? I think not.

Users don't know in advance whether they are cloning a repository with sub-modules or not until they do it. And if they non-recursively clone a repository that does have submodules, they end up with a cloned repository that is broken and will not build, and requires them to search for help on advanced git features in order to correct the problem. The converse is not a problem. Recursively cloning a repository without submodules is completely harmless. When they do break a clone by cloning it non-recursively, VS Code does not (and probably will never) provide a command in the UI to fix the problem (git submodule init --recursive, or something to that effect).

If it helps, the rest of the VS Code UI handles submodules properly, once they have been initialized. I work with this daily on several projects. Submodules can be pulled and branched and merged, and updates are properly propagated to parent projects (i.e. .gitmodules and repository state of the parent project(s) are updated correctly). So I don't think there's a significant risk of complications here.

I know it sounds brave, but I think it is actually not. All you're doing is preserving a truly unfortunate git-ism. The right thing to do, I think, is to change the behavior of the existing button and always clone and init recursively. Or perhaps, if you're feeling cowardly ( :-) ) -- careful, yes that's what I meant, careful -- add a Recursive checkbox that defaults to true. Although I truly think that you don't need the option. Clones should always be recursive. Anything less produces a broken clone that won't build.

Apologies for not having tracked the issue more carefully, and caught the issue before it was implemented. I'm not sure if I missed updates in my email or whether we don't get notified of intermediate processing of CRs.

Does this issue occur when all extensions are disabled?: Yes/No
Yes.

• VS Code Version: Insider releases build associated with issue Git - Submodules are not processed when cloning a git project. #227150
• OS Version: Not installed, but using Ubuntu (x86_64 and aarch64), and Raspberry Pi O/S.

Steps to Reproduce:

1. Any of several ways to clone a github project.
2. The insider release now dispays two buttons to clone -- Clone, and Clone(recursive), according to Git - Submodules are not processed when cloning a git project. #227150.
3. There should only be one button.