Am 05.01.2013 14:52, schrieb Manlio Perillo:
> Il 04/01/2013 22:51, Junio C Hamano ha scritto:
>> Manlio Perillo <> writes:
>>> $ git submodule update --init
>>> ...
>>> Submodule 'roms/vgabios' (git:// registered
>>> for path 'roms/vgabios'
>>> fatal: unable to connect to
>>>[0:]: errno=Connection timed out
>>> Unable to fetch in submodule path 'pixman'
>>> $ git submodule update --init
>>> fatal: Needed a single revision
>>> Unable to find current revision in submodule path 'pixman'
>>> The problem is easy to solve: manually remove the pixman directory;
>>> however IMHO git submodule update should not fail this way since it may
>>> confuse the user.
>> Sounds like a reasonable observation.  Jens, Heiko, comments?
> I have found another, related problem.
> Today I tried to update qemu submodules again, however the command
> failed with an "obscure" error message:
> $ git submodule update pixman
> fatal: Needed a single revision
> Unable to find current revision in submodule path 'pixman'
> The pixman submodule is the one that I failed to update in the very begin.
> The problem is not with the pixman or qemu repository: if I clone again
> qemu (with the --recursive option), all is ok.
> The problem is with the private working copy (in .git/modules/pixman)
> being corrupted:
> $git log
> fatal: bad default revision 'HEAD'.
> The HEAD file contains "ref: refs/heads/master", but the refs/heads
> directory is empty.

Yep, as I explained in my other email the partially set up
.git/modules/pixman is the reason for the trouble you have.

> By the way: since git submodule is a porcelain command, IMHO it should
> not show to the user these low level error message; at least it should
> give more details.
> As an example, in this case it could say something like:
>   the local module "pixmap" seems to be corrupted.
>   Run xxx to remove the module and yyy to create it again.
> The ideal solution is, for submodule update, to never leave an
> incomplete directory; that is: the update command should be atomic.

I agree that submodule update should not leave an inconsistent state.
In that case you wouldn't see any low level error messages (which I
think is ok if something the porcelain didn't expect to happen occurs,
like it did here).
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to