Re: ''git submodule sync'' should not add uninitialized submodules to .git/config

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 23.06.2011 16:35, schrieb Junio C Hamano:
> Maarten Billemont <lhunath@gmail.com> writes:
> 
>> When I initialize 2/3 submodules of my git repository and do git
>> submodule update, all is fine: Only the 2 submodules that I need are
>> updated.
>>
>> When I run a git submodule sync to update the URLs that may have been
>> changed in .gitmodules, it ADDS the URL of the submodule that was NOT
>> initialized, thus "initializing" it.
>>
>> Now, when I run git submodule update, it starts checking out the third
>> module and my workflow is broken.
> 
> See 33f072f (submodule sync: Update "submodule.<name>.url" for empty
> directories, 2010-10-08), which introduced this behaviour.
> 
> cmd_update considers anything that has submodule.<name>.url defined as
> "the user is interested", so I suspect "git submodule sync" should not do
> this.
> 
> The situation 33f072f cites as needing this behaviour can easily fixed by
> running 'submodule sync' after switching to the branch to which the
> submodule _matters_, no?
> 
> Jens, what do you think?

I agree that 33f072f introduced a regression. One could argue if it was
a good idea to let "git submodule init" not do the clone itself but defer
it to "git submodule update" by setting the url in .git/config, but that's
the way things are done now (and maybe there was a very good reason to do
it that way I'm not aware of, because I didn't follow the list that closely
back then).

So while I think 33f072f solved a problem for a valid use case, it breaks
other use cases that worked so far. So unless we want to change init to do
the clone itself (which would be a pretty invasive change in behavior),
I'd vote for a revert.