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 . 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