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 [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
