Am 23.06.2011 16:35, schrieb Junio C Hamano: > Maarten Billemont <lhunath@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html