Am 04.04.2013 19:10, schrieb Chris Wilson:
> 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
... or:
(c) Enter the correct URL in .git/config.
> (b) doing "git submodule rm" and then "git checkout .gitmodules" to undo the
> damage to that file.
Hmm ... that leaves your superproject dirty, right?
(d) Update the .gitmodules file to use the correct URL (you
want to do a commit fixing that anyway, no? ;-) and do a
"git submodule sync", which will copy the corrected URL
into .git/config.
> 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?)
No, because .gitmodules still contained the broken URL which a
sync then copies into .git/config again.
> * git submodule init (ignores them, because they're already in .git/config?)
Correct.
> * git submodule update (still fails because the URL in .git/config is wrong).
Sure.
> 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 automatically.
I doubt deinit will help here (except after running that you'll
be able to use "git submodule update" to populate the remaining
submodules) unless you fix the broken URL in .git/config or
.gitmodules.
> 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?
Hmm, at first glance this looks like a pilot error. Maybe we could
update the documentation to help other users falling into that
trap or extend some commands to be a bit more helpful in such a
case, but it looks like the behavior you observed is documented
(while fixing the problem you observed isn't explicitly). Also an
option for "git submodule update" to continue even if it fails to
populate some submodules might help here.
--
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
