Am 01.12.2012 17:30, schrieb W. Trevor King: > On Sat, Dec 01, 2012 at 04:38:02PM +0100, Jens Lehmann wrote: >> You need to handle the 'url' setting differently. While I think the 'update' >> setting should not be copied into .git/config at all (because it makes it >> impossible for upstream to change that later without the user copying that >> himself as 'sync' doesn't do that) the 'url' setting in .git/config has two >> important implications: >> >> 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). > Perhaps `submodule init` should be reduced to just wrap: > > $ git config submodule.<name>.update checkout > > where the default update configuration would be 'none'. > >> 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? >>> [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. -- 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
