switching branches when they use different submodule remotes

I was confused earlier today when I switched branches in a repo with libgit2 in a submodule.

I knew that the different branches used different remotes for the submodule -- one remote is older, the other remote has newer development.

   git://github.com/pieter/libgit2.git
   git://repo.or.cz/libgit2.git

so when I switched I deleted the whole libgit2 dir and ran:

   git submodule init
   git submodule update

I was switching to the branch that referenced git://github.com/pieter/libgit2.git and I was surprised the newer branch was cloned instead.

Looking at the doc for git submodule:

   http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html

it made it clear that executing init does not alter existing information in .git/config so I deleted the reference in ./git/config manually and started over.

Is there a better way to handle this?

Stephen Bannasch <stephen.bannasch@deanbrook.org> writes:

Perhaps "submodule sync"?

There are at least two different scenarios where you may have multiple URLs for a given submodule path.

 - These two URLs may represent two projects with different histories, and
   depending on the commit that is checked out, your superproject may want
   to use a URL for the repository that appears in .gitmodules that is
   checked out.  "submodule sync" would be one solution for this case.

 - These two URLs may represent a single project but the repository
   migrated and the old URL may not even work anymore.  In such a case,
   even when you checked out an old commit of the superproject, you do not
   want to use the old and now decommissioned URL in the .gitmodules file.

There can be combinations and variants of the above two.

In very early days of "git submodule" Porcelain support, there were a lot of design discussion taking these two situations into account. I don't recall the details, but the core idea was:

 - record a tuple <the value chosen by the user, the value the user saw in
   .gitmodules when the user chose the value> in .git/config;

 - when .gitmodules has a value that the user has not seen, ask the user
   what to do. The user may want to use the value recorded in .gitmodules,
   or may want to use the value already in .git/config.  This would result
   in a new tuple <the value chosen, the value in .gitmodules> recorded in
   .git/config;

 - when .gitmodules has a value that the user has seen, use the
   corresponding value the user chose to use.

which would have solved both use cases; unfortunately, nobody has been inclined to implement anything like that so far.