On Sat, Dec 01, 2012 at 04:38:02PM +0100, Jens Lehmann wrote: > Am 30.11.2012 18:53, schrieb W. Trevor King: > > In my v5 patch, I check for submodule.<name>.remote first in the usual > > `git config` files. If I don't find what I'm looking for I fall back > > on .gitmodules (basically Jens' suggestion). However, my initial > > copying-to-.git/config approach was mostly done to mimic existing > > configuration handling in git-submodule.sh. Since I agree with Jens > > on configuration precendence, and I now had two options to read > > (.branch and .remote), I thought I'd pull the logic out into its own > > function (code included at the end). While I was shifting the > > existing submodule config handling over to my new function, I noticed > > that with this logic, `submodule init` doesn't really do anything > > important anymore. Likewise for `submodule sync`, which seems to be > > quite similar to `init`. > > 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. 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`. > > [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. 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