Re: Re: [RFC PATCH] clone: add clone.recursesubmodules config option
On Thu, Jun 05, 2014 at 11:18:28AM -0700, Junio C Hamano wrote: Jens Lehmann jens.lehm...@web.de writes: We had two settings in mind,... So what if clone would just do an git submodule init for now when submodule.autoinit is set but submodule.autoupdate isn't [?] ... and a single submodule.auto setting would be what users really want? I do not offhand think of a sensible scenario where you want to init a submodule once but do not want to update it when the superproject changes. Even if the user uses the mode to detach the submodule HEAD, i.e. the branches in submodules do not matter and the whole tree is described by the superproject's commit and gitlinks recorded in it, the user would want the new objects necessary for the updated superproject, which means a submodule that is init'ed (whether it is via git submodule init or the submodule.autoinit variable) must be updated. So I am not sure why a user wants to disable autoupdate in the first place. For the same reason, setting submodule.*.update to none would not make much sense, either. Perhaps I am missing something. Unless the user is very conservative and suspects that these recursive behaviour we are going to bolt on to various commands could be buggy and untrustworthy, in which case the user might want to manually run git submodule update, or even run git fetch after going there while bypassing the whole git submodule. But I do not think that is healthy in the longer run. I think autoupdate is mainly there for the transition phase. Since submodule can e.g. contain a lot of files a checkout would take much longer. Similar to when Jens implemented the recursive diff, many people were annoyed by the new files showing up and some with the impact on performance (thats why we have the --ignore-submodules option). In case of very big submodules and people already ignore their diff it might even be necessary that the update is only done manually. E.g. for a big media repository. Cheers Heiko -- 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
Re: Re: [RFC PATCH] clone: add clone.recursesubmodules config option
On Thu, Jun 05, 2014 at 07:48:33PM +1200, Chris Packham wrote: On 05/06/14 07:42, Heiko Voigt wrote: 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 = * Thats interesting. Lets me/us think about that a little more. 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. 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? autoclone is about cloning the history of submodules. So e.g. when a submodule first appears in the superprojects history whether it should automatically be cloned to .git/modules. autoinit is all about the checkout phase. When a commit with a new submodule is checked out: Should that new submodule be automatically initialised? As far as autoupdate is concerned: Maybe autoinit can imply that it is enabled, yes. But I guess we still need autoupdate for the case of big submodules that cause to much performance trouble if updated by every checkout. So its actually three values: autoclone, autoinit, autoupdate. Damn, these configurations become more complicated everytime. Maybe we should try to clean them, up once we have everything, with Git 3.0 ;-) If anyone has an idea how to get rid of some right now... Radically different thinking: How about just one: submodule.auto = true/false configuration and that means you opt in to doing everything as automatic as possible. Since we are still implementing we could stick a prominent warning in the documentation that the user should be prepared for behavioral changes. Once everybody is happy with that we could switch the default from false to true. 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. Yep thats exactly what we already do at $dayjob but with submodule.*.update=none. Since that conveniently also disables the initialisation, developers only get the basic code and not everyone needs to have the media and some big external libs. I would reuse 'update' in the long run. But I guess for the transition we will need the extra autoupdate one to keep annoyance levels low. We currently also do not have real use cases for the tags/views scenario, but as repositories grow I can see that it could be useful so I would like it if we could keep the
Re: Re: [RFC PATCH] clone: add clone.recursesubmodules config option
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. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
