mailing list mirror (one of many)
 help / Atom feed
From: Stefan Beller <>
To: Brandon Williams <>
Cc: Ralf Thielow <>, git <>
Subject: Re: git-clone ignores submodule.recurse configuration
Date: Mon, 4 Dec 2017 12:02:36 -0800
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Dec 1, 2017 at 1:47 PM, Brandon Williams <> wrote:
> On 12/01, Ralf Thielow wrote:
>> Today I played around a bit with git submodules and noticed
>> that the very handy configuration "submodule.recurse" is not
>> working for the git-clone command.

The rationale here is that submodule.recursive ought to make your
conglomerate of repositories (superproject + some submodules)
look and feel like one giant repository.  Thinking further this sounds
like a user wants to set it globally, hence it may be expected to
work for fresh clones, too.

However at clone time, we don't know which submodules the
user wants. The first submodule recursive switches were an
all or nothing, but I think we need a better selection there.
For fetch there is an "only-those-needed" selection as
"on-demand". Similar for push.

For clone we expected the user wanting to specify which
submodules are interesting:

  git clone --recurse-submodule=<pathspec>

(Note to self: the `[=<pathspec]` part is deep down in the
man page, not in the synopsis, we may want to put that
more prominently there)

Maybe when submodule.recursive is set, we should assume
a pathspec of "." (everything), also see to ``,
which is set using the argument from git-clone.

>> "git help config" tells me that submodule.recurse affects
>> all commands that have a --recurse-submodules option.
>> git-clone seems to be an exception which is also mentioned in
>> a workflow example in Documentation/gitsubmodules.txt that
>> says:
>>   # Unlike the other commands below clone still needs
>>   # its own recurse flag:
>>   git clone --recurse <URL> <directory>
>>   cd <directory>
>> So this seems to be a known issue. Is someone already
>> working on this or has a plan to do it? Or is there a reason
>> not doing this for git-clone but for git-pull?
> When we introduced the "submodule.recurse" config we explicitly had it
> not work with clone because a recursive clone ends up pulling data from
> other sources aside from the URL the user explicitly provides.
> Historically there have been a number of security related bugs with
> respect to cloning submodules so we felt it was best to require a
> recursive clone to be requested explicitly, at least for the time being.
> --
> Brandon Williams

      reply index

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-01 18:48 Ralf Thielow
2017-12-01 21:47 ` Brandon Williams
2017-12-04 20:02   ` Stefan Beller [this message]

Reply instructions:

You may reply publically 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:
       or Tor2web:

AGPL code for this site: git clone public-inbox