Cannot push a commit

Dear List,

I have a big problem with a file which I cannot push to my central git repository. The file can be found here: http://dl.fechner.net/APP_UD.sch

What I did to reproduce it: On my server (freebsd with git 1.7.8.3) cd mkdir git-test cd git-test git init --bare

On my client a windows pc with tortoise git 1.7.6.0 and git 1.7.8.msysgit.0 I cloned the repository over ssh Added a small test.txt file, commit and pushed it to the server, everything is fine. Then a copied the file above to the local repo, added it and commited it. If I try to push it, I get the error message: 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'

git config -l shows on the windows pc: core.symlinks=false core.autocrlf=false color.diff=auto color.status=auto color.branch=auto color.interactive=true pack.packsizelimit=2g help.format=html http.sslcainfo=/bin/curl-ca-bundle.crt sendemail.smtpserver=/bin/msmtp.exe diff.astextplain.textconv=astextplain rebase.autosquash=true user.name=Matthias Fechner user.email=idefix@fechner.net core.autocrlf=false core.safecrlf=false core.repositoryformatversion=0 core.filemode=false core.bare=false core.logallrefupdates=true core.symlinks=false core.ignorecase=true core.hidedotfiles=dotGitOnly remote.origin.fetch=+refs/heads/*:refs/remotes/origin/* remote.origin.url=idefix@fechner.net:git-test remote.origin.puttykeyfile= branch.master.remote=origin branch.master.merge=refs/heads/master

How can I solve this problem? Is this maybe a bug in git?

Thanks a lot Matthias

Am 15.01.2012 10:09, schrieb Matthias Fechner:

where should I raise a bug report for this?

Bye Matthias

On Sun, Jan 15, 2012 at 10:09:52AM +0100, Matthias Fechner wrote:

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

Am 16.01.2012 22:20, schrieb Jeff King:

thanks a lot for your answer. I created a new repository which is not a bare repo to use your commands posted above (i tested it with the normal push command from the client and same error).

I created the bundle on the client, copied it with winscp to the server
and it was applied fine to the repository:
$ git pull ../foo.bundle master
Receiving objects: 100% (3/3), 91.63 KiB, done.
From ../foo.bundle
 * branch            master     -> FETCH_HEAD
Updating 53b9b5e..301e730
Fast-forward
 APP_UD.sch |19643
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 19643 insertions(+), 0 deletions(-)
 create mode 100644 APP_UD.sch

So the problem should be located anywhere else. I tested now the same on a mac osx as client and there everything works as expected, I added the file, commited it and pushed it without errors to the server.

So the problem has something to do with windows as client. I will do some additional test this evening.

Where can we continue to search?

Bye Matthias

Am 17.01.2012 08:35, schrieb Matthias Fechner:

the problem seems to be located in the ssh.exe which comes with git. (location in the standard windows install is: C:\Program Files (x86)\Git\bin )

I downloaded plink.exe from the putty project and copied it into a directory where the PATH variable points to.

Then I opened the git bash and inserted:
export GIT_SSH=plink.exe
git push
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 91.63 KiB | 123 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To idefix@fechner.net:git-test
   8020989..6ea6180  master -> master

The currently installed version is OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007. Maybe an updated openssh version in the git bin folder will solve the problem?

Bye Matthias

On Wed, Jan 18, 2012 at 07:25:02PM +0100, Matthias Fechner wrote:

Thanks for following up on this. It does seem like openssh is dropping your connection in a half-duplex way, though we don't know why. A bug in openssh sounds like a reasonable candidate...

Especially given how old your version is. Certainly I would try with a more recent version. If it clears up the problem, I'm willing to assume it's an openssh bug that's been fixed. If it doesn't, then it may be an open openssh bug, or perhaps there is some problem in the way we're invoking it on Windows. We can investigate that path if need be.

-Peff

Am 19.01.2012 03:09, schrieb Jeff King:

I was now able to track the problem down to the command which is causing the problem. If you install git and you have tortoise-svn installed the installer select as ssh client tortoiseplink.exe and this is the program which has the bug. I changed the system back to the ssh.exe which comes with the git installer and it is working fine. I downloaded the plink.exe (dev version) for the putty homepage and it works fine. If i use the tortoiseplink.exe again it fails.

Hopefully this will help some ppl to solve there problem too.

I'll start to do some tests if the same problem will raise with svn too and I ask the tortoise-svn devs to replace the tortoiseplink.exe by a newer version. Thanks a lot for your help.

Bye Matthias