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

[Heiko Voigt <hvoigt@hvoigt.net>]

On Thu, Jun 05, 2014 at 07:48:33PM +1200, Chris Packham wrote:
> On 05/06/14 07:42, Heiko Voigt wrote:
> > I like this idea of specifying different "views" by giving tags. But
> > does it rule out a boolean clone.recursesubmodules? For the simple case
> > some people might not want to worry about specifying tags but just want
> > to configure: "Yes give me everything". So if we were to do this I would
> > like it if we could have both. Also because the option for clone is
> > --recurse-submodules and our typical schema is that a configuration
> > option is named similar so clone.recursesubmodules would fit here.
> 
> Maybe using a glob pattern would work.
> 
> The user might say
> 
>      [clone]
>          recursesubmodules = x86*
> 
> And .gitmodules might say
> 
>      [submodule "foo"]
>          tags = x86_64
>      [submodule "bar"]
>          tags = x86
>      [submodule "frotz"]
>          tags = powerpc
> 
> For the "Yes give me everything" case the user could say
> 
>      [clone]
>          recursesubmodules = *

Thats interesting. Lets me/us think about that a little more.

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

We currently also do not have real use cases for the tags/views
scenario, but as repositories grow I can see that it could be useful so
I would like it if we could keep the configuration open to that.

Cheers Heiko