On Wed, Jun 04, 2014 at 10:24:06AM -0700, Junio C Hamano wrote: > 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. 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. 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 -- 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
