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

From: Jens Lehmann <jens.lehmann@web.de>
Date: Jun 23, 2011, 19:14 UTC
Message-ID: <4E0390A7.8040505@web.de>
In-Reply-To: <7v7h8c4nv3.fsf@alter.siamese.dyndns.org>

Am 23.06.2011 16:35, schrieb Junio C Hamano:

Show 25 quoted lines

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