Am 05.01.2013 14:52, schrieb Manlio Perillo: > Il 04/01/2013 22:51, Junio C Hamano ha scritto: >> Manlio Perillo <manlio.perillo@xxxxxxxxx> writes: > >>> $ git submodule update --init >>> ... >>> Submodule 'roms/vgabios' (git://git.qemu.org/vgabios.git/) registered >>> for path 'roms/vgabios' >>> fatal: unable to connect to anongit.freedesktop.org: >>> anongit.freedesktop.org[0: 131.252.210.161]: 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html