Am 06.06.2014 07:54, schrieb Heiko Voigt: > On Thu, Jun 05, 2014 at 07:48:33PM +1200, Chris Packham wrote: >> On 05/06/14 07:42, Heiko Voigt wrote: >>> 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? To me those two only make sense together, so I see them as a single option. But then maybe some developers would like to clone everything so they are plane-safe in case they intend to do "git submodule update --init" later at 30.000 feet without internet access ... so yes, technically we have three distinct steps: clone, init & update. > 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... I suspect that once they are introduced we'll never be able to get rid of them again ;-) > 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. I like that. (And if we really need /clone-but-no-init-or-update/ or /clone-and-init-but-no-update/ settings later we could add two new values additionally to true/false to make that work with a single setting too). So I'm convinced that a single option is the way to go. >> 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. I'm not sure reusing 'update' is going to work: 'update' currently controls what "git submodule update" will do: nothing, checkout, merge or rebase (and we shouldn't change that because of backwards compatibility). We're talking about a new setting telling regular git commands to do the submodule work tree update without having to manually call "git submodule update". And I believe we'll always need 'update' as it is for people who'll want to do a manual "git submodule update", especially when we change the default of 'submodule.auto' to true in 3.0. And by the way: wouldn't it make more sense to tell the user /what/ we do automatically? So maybe 'submodule.autoupdate' is a better name for the new switch? The fact that it also does clone and init under the hood looks more like a technical detail to the user, no? And I'd like to avoid users uttering "auto-what?" when they hear about this setting ;-) And it would make clear that 'update' is what we do and 'autoupdate' makes it happen without having to call "git submodule update". -- 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