From: Jens Lehmann Date: Thu, 23 Jun 2011 19:14:47 GMT Subject: Re: ''git submodule sync'' should not add uninitialized submodules to .git/config 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: > Maarten Billemont 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..url" for empty > directories, 2010-10-08), which introduced this behaviour. > > cmd_update considers anything that has submodule..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.