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

From: Heiko Voigt <hvoigt@hvoigt.net>
Date: Jun 6, 2014, 05:54 UTC
Message-ID: <20140606055430.GC77405@book.hvoigt.net>
In-Reply-To: <539020D1.1090601@gmail.com>

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

Show 29 quoted lines

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

Show 29 quoted lines

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

Show 20 quoted lines

> 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