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

On 05/06/14 07:42, Heiko Voigt wrote:

On Wed, Jun 04, 2014 at 10:24:06AM -0700, Junio C Hamano wrote:

quoted

Chris Packham [off-list ref] writes:

quoted

On 04/06/14 09:05, Junio C Hamano wrote:

quoted

quoted

Also, going --recursive when the user did not want is a lot more
expensive mistake to fix than not being --recursive when the user
wanted to.

Having said all that, I do not mean to say that I am opposed to
introduce some mechanism to let the users express their preference
between recursive and non-recursive better, so that "git clone"
without an explicit --recursive (or --no-recursive) can work to
their taste.  A configuration in $HOME/.gitconfig might be a place
to start, even though that has the downside of assuming that the
given user would want to use the same settings for all his projects,
which may not be the case in practice.

And here's a quick proof of concept. Not sure about the config variable name
and it could probably do with a negative test as well.

I would be more worried about the semantics than the name, though;
re-read the part you quoted with extra stress on "has the downside".

I think I heard the submodule folks (cc'ed) discuss an approach to
allow various submodules to be marked with "tags" with a new type of
entry in .gitmodules file in the superproject, and use these tags to
signal "by default, a new clone will recurse into this submodule".

E.g. if projects standardized on "defaultClone" to mark such
submodules, then $HOME/.gitconfig could say

    [clone]
        recursesubmodules = defaultClone

Or the projects may mark platform specific submodules with tags,
e.g. a .gitmodules in a typical superproject might say something
like this:

    [submodule "posix"]
    	path = ports/posix
        tags = linux obsd fbsd osx
    [submodule "windows"]
        path = ports/windows
        tags = win32
    [submodule "doc"]
    	path = documentation
        tags = defaultClone

and then the user's $HOME/.gitconfig might say

    [clone]
        recursesubmodules = defaultClone win32

to tell a "git clone" of such a superproject to clone the top-level,
read its .gitmodules, and choose documentation/ and ports/windows
submodules but not ports/posix submodule to be further cloned into
the working tree of the superproject.

Of course, if this kind of project organization proves to be useful,
we should try to standardize the set of tags early before people
start coming up with random variations of the same thing, spelling
the same concept in different ways only to be different, and if that
happens, then we could even give a non-empty default value for the
clone.recursesubmodules when $HOME/.gitconfig is missing one.

Just a random thought.

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 = *

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.

Cheers Heiko

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?

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.