Re: Cannot push a commit

[Jeff King <peff@peff.net>]

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@fechner.net:git-test
> ! [remote rejected] master -> master (n/a (unpacker error))
> error: failed to push some refs to 'idefix@fechner.net: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