From: Ben Avison <email@example.com>
To: Duy Nguyen <firstname.lastname@example.org>
Cc: Git Mailing List <email@example.com>
Subject: Re: [PATCH] clone: add `--remote-submodules` flag
Date: Thu, 16 May 2019 18:50:45 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 16/05/2019 12:31, Duy Nguyen wrote:
> On Tue, May 14, 2019 at 2:46 AM Ben Avison <email@example.com> 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.
next prev parent reply other threads:[~2019-05-16 18:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-13 17:59 [PATCH] clone: add `--remote-submodules` flag Ben Avison
2019-05-13 21:12 ` Ævar Arnfjörð Bjarmason
2019-05-14 18:38 ` Ben Avison
2019-05-19 14:26 ` [PATCH v2] " Ben Avison
2019-05-16 11:31 ` [PATCH] " Duy Nguyen
2019-05-16 17:50 ` Ben Avison [this message]
2019-05-18 11:40 ` Duy Nguyen
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).