Re: [RFC PATCH] clone: add clone.recursesubmodules config option

Heiko Voigt [off-list ref] writes:

On Thu, Jun 05, 2014 at 07:48:33PM +1200, Chris Packham wrote:
...

quoted

I'm a little confused at how autoclone and autoinit differ. Aren't they
the same? i.e. when this module appears grab it by default. I see
autoupdate as a little different meaning update it if it's been
initialised. Also does autoinit imply autoupdate?

autoclone is about cloning the history of submodules. So e.g. when a
submodule first appears in the superprojects history whether it should
automatically be cloned to .git/modules.

autoinit is all about the checkout phase. When a commit with a new
submodule is checked out: Should that new submodule be automatically
initialised?

As far as autoupdate is concerned: Maybe autoinit can imply that it is
enabled, yes. But I guess we still need autoupdate for the case of big
submodules that cause to much performance trouble if updated by every
checkout.

So its actually three values: autoclone, autoinit, autoupdate. Damn,
these configurations become more complicated everytime.

I suspect that as an end-user you do not need to set all three in
most cases.  Just like an unspecified autoupdate can default to
whatever autoinit setting for the submodule is, because it is less
likely that a user wants to have a submodule checked out *and* leave
it stale, an unspecified autoinit can default to the autoclone
setting, because it is less likely that a user who does not want to
have a checkout would want to spend network bandwidth to clone it.