reassign 703286 git-bzr git/1:1.8.2-1 retitle 703286 git-remote-bzr: fetch fails with "fatal: bad object 0000000000000000000000000000000000000000" found 703286 git/1.8.2~rc3-1 tags 703286 + upstream quit
Hi, Guillem Jover wrote: > Another issue with git-remote-bzr, it chokes on a bad object with a 0* > hash. I've found this on at least two repos: > > $ git remote -v > origin bzr::lp:upstart (fetch) > origin bzr::lp:upstart (push) > $ git remote -v > origin bzr://bzr.savannah.nongnu.org/libpipeline/trunk/ (fetch) > origin bzr://bzr.savannah.nongnu.org/libpipeline/trunk/ (push) > $ git fetch > [... some "WARNING: TODO: fetch tag" omitted ...] > fatal: bad object 0000000000000000000000000000000000000000 > error: bzr://bzr.savannah.nongnu.org/libpipeline/trunk/ did not send all > necessary objects Yes, I can reproduce this. The initial clone works fine, but later "git fetch" quickly emits fatal: bad object 0000000000000000000000000000000000000000 error: bzr::lp:upstart did not send all necessary objects "GIT_TRACE=1 git fetch" tells me the command emitting that message is "git rev-list --objects --stdin --not --all", called by check_everything_connected(). Presumably the ref_map does not have values filled in, though it should. Tracing back further, the underlying cause *might* be the transport machinery not coping well with remote helpers that do not know what commit each remote ref points to. In response to the "list" command they give ? refs/heads/master ? refs/tags/0.6.0-2 ... which gets translated into the ls-remote output 0000000000000000000000000000000000000000 refs/heads/master 0000000000000000000000000000000000000000 refs/tags/0.6.0-2 ... Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org