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

[Ben Avison <bavison@riscosopen.org>]

On 16/05/2019 12:31, Duy Nguyen wrote:
> 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