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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 6, 2014, 16:35 UTC
Message-ID: <xmqqmwdqq9lg.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20140606055430.GC77405@book.hvoigt.net>

Heiko Voigt <hvoigt@hvoigt.net> writes:

Show 19 quoted lines

> On Thu, Jun 05, 2014 at 07:48:33PM +1200, Chris Packham wrote:
> ...
>> 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.