Re: [PATCH] clone: add `--remote-submodules` flag

From: Ben Avison <bavison@riscosopen.org>
Date: May 16, 2019, 17:50 UTC
Message-ID: <1376dce1-6ca1-88f2-97c9-c8dd2ac683a1@riscosopen.org>
In-Reply-To: <CACsJy8B589nOPNt6143BNQNojRYn4pyQCMNZKLRn+EGyWD4-mw@mail.gmail.com>

On 16/05/2019 12:31, Duy Nguyen wrote:

Show 12 quoted lines

> On Tue, May 14, 2019 at 2:46 AM Ben Avison <bavison@riscosopen.org> wrote:
>>
>> When using `git clone --recurse-submodules` there was previously no way to
>> pass a `--remote` switch to the implicit `git submodule update` command for
>> any use case where you want the submodules to be checked out on their
>> remote-tracking branch rather than with the SHA-1 recorded in the superproject.
> 
> Are there any other submodule options that could be useful passing
> from git-clone as well? What I'm getting at is, if there are multiple
> of them, perhaps we need a different/generic approach than introducing
> a bunch of --<something>-submodules. But of course if --remote is the
> only useful one left, then it's moot.

That's an interesting point. However, for many of the switches, it only makes sense to set them one way when you're calling `git submodule update` within `git clone --recurse-submodules`.

--quiet: already inherited from `git clone`

--progress: already inherited from `git clone`

--force: wouldn't have any effect since there cannot be any local changes to override yet

--remote: this is what my patch is adding support for

--no-fetch: since any submodules will be freshly cloned, there is no need to fetch from them again already, so you'd always want this on (as far as I'm aware, this only has effect when you also use --remote, so I've made it conditional on that)

--checkout/--rebase/--merge: since there cannot be any local changes to rebased or merged yet, these wouldn't have any effect, and it's fine to leave them as the default (--checkout)

--init: you always want this in this case

--reference/--dissociate: I suppose you might want these in theory? However, as far as I understand, it's only really useful for `git submodule update` if the superproject only contains a single submodule, since each submodule would require a different reference repository.

--recursive: at present this is applied unconditionally. I suppose you might only want to recurse to one level, but I'd think that's rare?

--depth: at present you only get to set this to a depth of 1, by passing `--shallow-submodules` to `git clone`. I suppose you might occasionally want a different depth, but again I'd expect that to be rare.

--no-recommend-shallow: there may be an argument for letting you set this one, and you can't at present

--jobs: already inherited from `git clone`

In summary, the most significant omission is --remote IMHO, though there may be an argument for adding a small number of others.

Ben