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

> 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?

> 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...

> 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.

>> 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.