Control: fixed -1 git/1:1.8.3~rc0-1 On Mon, 2013-04-01 at 00:30:44 -0700, Jonathan Nieder wrote: > 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 > ...
This works now for me with latest upload, marking as fixed instead of closing in case you want to do that in the changelog. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
