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 [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. -- 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