On 05/06/14 07:42, Heiko Voigt wrote:
> On Wed, Jun 04, 2014 at 10:24:06AM -0700, Junio C Hamano wrote:
>> Chris Packham <judge.pack...@gmail.com> writes:
>>> On 04/06/14 09:05, Junio C Hamano wrote:
>>>>> 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

         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

         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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to