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
More majordomo info at

Reply via email to