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

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 06.06.2014 07:54, schrieb Heiko Voigt:
> On Thu, Jun 05, 2014 at 07:48:33PM +1200, Chris Packham wrote:
>> On 05/06/14 07:42, Heiko Voigt wrote:
>>> So either we do this "magically" and all valid boolean values are
>>> forbidden as tags or we would need a different config option. Further
>>> thinking about it: Maybe a general option that does not only apply to
>>> clone would suit the "views" use-case more. E.g. "submodule.tags" or
>>> similar.
>>>
>>> Also please note: We have been talking about adding two configurations
>>> for submodules:
>>>
>>> 	submodule."name".autoclone (IIRC)
>>>
>>> I am not sure whether that was the correct name, but this option should
>>> tell recursive fetch / clone whether to automatically clone a submodule
>>> when it appears on a fetch in the history.
>>>
>>> 	submodule."name".autoinit
>>>
>>> And this one is for recursive checkout and tells whether an appearing
>>> submodule should automatically be initialized.
>>>
>>> These options fullfill a similar use-case and are planned for the future
>>> when recursive fetch/clone and checkout are in place (which is not that
>>> far away). We might need to rethink these to incoporate the "views from
>>> tags" idea nicely and since we do not want a configuration nightmare.
>>
>> 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?

To me those two only make sense together, so I see them as a single
option. But then maybe some developers would like to clone everything
so they are plane-safe in case they intend to do "git submodule
update --init" later at 30.000 feet without internet access ... so
yes, technically we have three distinct steps: clone, init & update.

> 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. Maybe we should
> try to clean them, up once we have everything, with Git 3.0 ;-) If
> anyone has an idea how to get rid of some right now...

I suspect that once they are introduced we'll never be able to get
rid of them again ;-)

> Radically different thinking: How about just one: submodule.auto =
> true/false configuration and that means you opt in to doing everything
> as automatic as possible. Since we are still implementing we could stick
> a prominent warning in the documentation that the user should be
> prepared for behavioral changes.
> 
> Once everybody is happy with that we could switch the default from false
> to true.

I like that. (And if we really need /clone-but-no-init-or-update/ or
/clone-and-init-but-no-update/ settings later we could add two new
values additionally to true/false to make that work with a single
setting too). So I'm convinced that a single option is the way to go.

>> At $dayjob we have a superproject which devs clone this has submodules
>> for the important and/or high touch repositories. We have other
>> repositories that are normally build from a tarball (or not built at
>> all) but we can build them from external repositories if needed. The
>> latter case is painfully manual. If autoinit/autoupdate existed we'd
>> probably setup out projects with.
>>
>>     [submodule "linux"]
>>         autoinit = true
>> 	autoupdate = true
>>     [submodule "userland"]
>>         autoinit = true
>> 	autoupdate = true
>>     [submodule "not-used-that-much"]
>> 	autoupdate = true
>>
>> We probably wouldn't make use of tags because we're building complete
>> embedded systems and generally want everything, even if we are doing
>> most of our work on a particular target we need to do builds for other
>> targets for sanity checks.
> 
> Yep thats exactly what we already do at $dayjob but with
> submodule.*.update=none. Since that conveniently also disables the
> initialisation, developers only get the basic code and not everyone
> needs to have the media and some big external libs.
> 
> I would reuse 'update' in the long run. But I guess for the transition
> we will need the extra autoupdate one to keep annoyance levels low.

I'm not sure reusing 'update' is going to work: 'update' currently
controls what "git submodule update" will do: nothing, checkout,
merge or rebase (and we shouldn't change that because of backwards
compatibility). We're talking about a new setting telling regular
git commands to do the submodule work tree update without having to
manually call "git submodule update". And I believe we'll always
need 'update' as it is for people who'll want to do a manual "git
submodule update", especially when we change the default of
'submodule.auto' to true in 3.0.

And by the way: wouldn't it make more sense to tell the user /what/
we do automatically? So maybe 'submodule.autoupdate' is a better
name for the new switch? The fact that it also does clone and init
under the hood looks more like a technical detail to the user, no?
And I'd like to avoid users uttering "auto-what?" when they hear
about this setting ;-) And it would make clear that 'update' is
what we do and 'autoupdate' makes it happen without having to call
"git submodule update".