Chris Packham <judge.packham@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html