From: Chris Packham <judge.packham@gmail•com>
To: Heiko Voigt <hvoigt@hvoigt•net>, Junio C Hamano <gitster@pobox•com>
Cc: git@vger•kernel.org, mara.kim@vanderbilt•edu,
Jonathan Nieder <jrnieder@gmail•com>,
Jens Lehmann <Jens.Lehmann@web•de>
Subject: Re: [RFC PATCH] clone: add clone.recursesubmodules config option
Date: Thu, 05 Jun 2014 19:48:33 +1200 [thread overview]
Message-ID: <539020D1.1090601@gmail.com> (raw)
In-Reply-To: <20140604194216.GA4636@sandbox-ub>
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.packham@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
[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.
next prev parent reply other threads:[~2014-06-05 7:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-03 18:11 Paper cut bug: Why isn't "git clone xxxx" recursive by default? Mara Kim
2014-06-03 19:52 ` Junio C Hamano
2014-06-03 21:05 ` Junio C Hamano
2014-06-03 22:24 ` Mara Kim
2014-06-04 9:30 ` [RFC PATCH] clone: add clone.recursesubmodules config option Chris Packham
2014-06-04 17:24 ` Junio C Hamano
2014-06-04 19:06 ` Jens Lehmann
2014-06-05 18:18 ` Junio C Hamano
2014-06-05 18:43 ` W. Trevor King
2014-06-06 5:26 ` Heiko Voigt
2017-08-02 18:11 ` Jeremy Morton
2017-08-02 20:34 ` Stefan Beller
2014-06-04 19:42 ` Heiko Voigt
2014-06-05 7:48 ` Chris Packham [this message]
2014-06-06 5:54 ` Heiko Voigt
2014-06-06 16:35 ` Junio C Hamano
2014-06-09 13:17 ` Jens Lehmann
2014-06-09 23:27 ` W. Trevor King
2016-10-03 15:36 ` Jeremy Morton
2016-10-03 17:18 ` Stefan Beller
2016-10-04 11:41 ` Heiko Voigt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=539020D1.1090601@gmail.com \
--to=judge.packham@gmail$(echo .)com \
--cc=Jens.Lehmann@web$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=hvoigt@hvoigt$(echo .)net \
--cc=jrnieder@gmail$(echo .)com \
--cc=mara.kim@vanderbilt$(echo .)edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox