On Sat, Dec 01, 2012 at 06:25:17PM +0100, Jens Lehmann wrote: > Am 01.12.2012 17:30, schrieb W. Trevor King: > > On Sat, Dec 01, 2012 at 04:38:02PM +0100, Jens Lehmann wrote: > > > 1) It tells the submodule commands that the user wants to have > > > that submodule populated (which is done in a subsequent "update" > > > after "init" copied the url there). > > > > Good point, but this should depend on submodule.<name>.update; > > having it as a side effect of a local submodule.<name>.url makes > > no sense. > > Sorry, but that makes tons of sense: url controls if the submodule > is to be populated and from where, update controls how (and can even > veto populating it if set to "none"). We /could/ do it differently, > but I can't see why we should (and risk severe compatibility issues). I think removing `init` will cause some compatibility issues anyway, so I was re-imaging how you do it. I don't think update='none' and "don't populate my submodule" are distinct ideas, while a locally configured url="somwhere" and "please populate my submodule" are (with the blank-url case defaulting to the superproject itself). > > > 2) It can be used to follow moving upstreams (think of checking > > > out an earlier commit before the upstream was moved, you won't > > > be able to clone it from there without having the new setting > > > persist). And which repository you follow is a matter of trust, > > > so the extra "git submodule sync" in that case is a good thing > > > to have. > > > > > > So I believe 'url' is the only setting that should be copied > > > into .git/config while all the others shouldn't. > > > > If you want to override the old repository location for an old > > commit, setting submodule.<name>.url makes sense. My rewritten > > `sync` updates the local submodule.<name>.url in the superproject > > if the configuration option is already set [1]. Perhaps a `sync > > --local` invocation should forcibly populate the local > > submodule.<name>.url to make this workflow easier. Bundling sugar > > for this special case should not happen under an extra command > > called `init`. > > What real world problems do we have with the current init/sync that > this approach would solve? I don't have any, but in my `update --remote` series I'm adding two new config options that are handled differently (define in .gitmodules, override in superproject .git/config) than existing submodules options. I'm trying to avoid confusing users by standardizing on the more flexible method, which avoids copying stuff into the superproject's .git/config, and under which the current `init` functionality doesn't make much sense. > > > > [snip get_submodule_config()] > > > > > > Something like that makes sense. You can use it for the settings > > > you add first and we can then reuse that for 'update' in a > > > separate patch later. > > > > I'm currently working out the details independently against > > v1.8.0. This will be a fairly major shift, so I think it should > > stay independent of `update --remote`. The `update --remote` > > stuff should be easy to adjust/rebase if the `init` > > removal/adjustment develops into something acceptable. > > I totally agree. Let's get the `update --remote` stuff ready first. Ok, but we'll have the possible confusion about option setting that I mention above. Still, it's good to minimize the number of irons in the fire, and an `init` removal will probably not get in until 2.0 anyway. If other people are fine with the different initialization paths, I'll put the init-removal on hold for now. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
Attachment:
signature.asc
Description: OpenPGP digital signature