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

Am 23.06.2011 16:35, schrieb Junio C Hamano:

Maarten Billemont [off-list ref] writes:

quoted

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.