If your git repo's .gitmodules contains a URL that you don't have access
to (for example you download someone else's code and it references a
submodule using their writable g...@github.com URL) then:
* git submodule init will add them to .git/config, with the wrong URLs.
* git submodule update will fail to check out the repos, leaving an empty
directory for the first one, and nothing for the others.
This state is broken (wrong URLs in .git/config), and AFAIK there's
nothing you can do to check out these submodules without either:
(a) manually hacking them out of .git/config, or
(b) doing "git submodule rm" and then "git checkout .gitmodules" to undo
the damage to that file.
The procedure I tried, which I expected to work, was:
* git submodule sync (doesn't sync them, because the directories don't
exist or don't contain a valid git repo?)
* git submodule init (ignores them, because they're already in
* git submodule update (still fails because the URL in .git/config is
The new deinit command may help, but for the wrong reasons. I don't want
to have to deinit my modules every time in the fabric deployment script,
just so that if they get into this state, they will get unbroken
It seems wrong to me that neither "git submodule init" nor "git submodule
sync" will modify the URL in .git/config, if the submodule is not already
checked out. I think I'd expect "git submodule init" to be idempotent, so
it would update the URLs in .git/config if they already exist, just like
it adds the URLs if they don't.
Any advice? Is this a real bug?
Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK
Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html