On 16/05/2019 12:31, Duy Nguyen wrote:
On Tue, May 14, 2019 at 2:46 AM Ben Avison <bavison@xxxxxxxxxxxxxx> 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
