On Sun, Jan 15, 2012 at 10:09:52AM +0100, Matthias Fechner wrote:
> git.exe push --progress "origin" master:master
>
> Counting objects: 4, done.
> Compressing objects: 100% (3/3)
> Writing objects: 100% (3/3), 80.00 KiB | 137 KiB/s
> Writing objects: 100% (3/3), 91.63 KiB | 137 KiB/s, done.
> Total 3 (delta 0), reused 0 (delta 0)
> fatal: early EOF
> error: unpack failed: unpack-objects abnormal exit
> To idefix@xxxxxxxxxxx:git-test
> ! [remote rejected] master -> master (n/a (unpacker error))
> error: failed to push some refs to 'idefix@xxxxxxxxxxx:git-test'
Odd. The unpacking process on the other end claims that it didn't get
the whole input (it knows how much to expect based on the earlier parts
of what is sent) . Yet the connection is still going (because we see the
error messages coming from the remote), so it wasn't simply that the
connection was dropped. So either:
1. Something in the connection cut out but only in a half-duplex way.
I guess I could see ssh doing that if its input pipe closed, but
that would mean the local pack-objects failed, and I believe git
already detects and reports that case.
2. The packfile sent indicated that it should have more bytes than it
does (i.e., either git indicated there were more objects than there
actually are, or zlib failed to give a stream-end marker in the
middle of an object). This is one of:
a. A bug in git or zlib.
b. Something in the connection corrupting the data (e.g., a
transport that is not 8-bit clean).
But in either 2a or 2b, I would expect us to have seen this before, and
I don't recall seeing anything like it.
You could try generating a bundle with this pack, like:
git bundle create foo.bundle master ^origin/master
and then shipping the resulting foo.bundle to the other side, and
pulling from it like:
git pull /path/to/foo.bundle master
That should use (roughly) the same pack generation code as the
push, but avoid the transport. If it works, then it's either a problem
with the transport, or there is something really subtle going on
inside git.
If it does fail, then that will be a much easier case to repeat and
diagnose from there.
-Peff
--
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