git pull hangs after "remote: Getting sizes..."

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Push new commits from source A to repo
2. Pull commits from repo on destination B and C

What is the expected output? What do you see instead?
Expected: New commits are fetched and merged
What's happening: git pull hangs at "remote: Getting sizes":

]# git pull
Password:
remote: Counting objects: 129, done
remote: Finding sources: 100% (128/128)
remote: Getting sizes: 100% (85/85)

And after a long time:

error: RPC failed; result=18, HTTP code = 200

What version of the product are you using? On what operating system?
Git:Blit 1.6.0, Tomcat 7.0.54, Java 1.7.0_45 on Solaris 10 (sparc)
Git 1.7.11.4 on Solaris 10 (sparc)
Git 1.7.1 on CentOS 6.5 (x86_64)

Please provide any additional information below.
I use Git:Blit to deploy code on development and production servers.
I develop the code on my workstation and push it to Git:Blit. Next I
pull these changes on the development hosts and later I pull them on
the production host.

I had this issue once a few weeks ago but I was busy with other stuff.
Today it happened again, on a different repository. I ff merged some
code from a local branch and pushed master to the repository. git pull
confirmed everything is up to date.

On my dev host I tried pulling the new commits and failed, git pull hangs
as seen above. For testing I tried fetching on the production host, same
result. I copied the local repository from the dev host to my workstation
and tried a pull there. Again git pull hangs after "remote: Getting sizes".
It seems all existing clones can no longer pull changes from the central
repository (all except the one I used to push the commits).

I tried restarting Git:Blit, running git gc in the local repository and in the
bare repository on the repository server, nothing helped. Git:Blit doesn't log
any issues, even with debugging activated.

I don't know if this is related to issue 485, because I can still freshly clone
the repository from the repo server. So I had to dump the existing repositories
on the dev and prod hosts, and clone from scratch to get it working again.

Original issue reported on code.google.com by d...@sigsegv.at on 9 Oct 2014 at 8:27

[GoogleCodeExporter]

Today i pushed another commit to this repository, and now I'm in the same 
situation as described in issue 485. Besides not being able to pull from this 
repository, I can't clone the repository anymore.

Original comment by d...@sigsegv.at on 10 Oct 2014 at 7:31

[GoogleCodeExporter]

Unfortunately, I don't have the free time to dig deeply into your issue.  But 
from your well-written and detailed report one thing that makes my Spidey-sense 
tingle is the use of Git 1.7.x.  The support for the http(s) transport was 
buggy in the 1.7.x series and had a series of nasty little surprises.

Things I recommend trying:
- does cloning via the git:// protocol work?
- does cloning via the ssh:// protocol work?
- can you update your Git client to 1.8.x, 1.9.x, 2.0.x or 2.1.x ?

Original comment by James.Mo...@gmail.com on 10 Oct 2014 at 12:18

[GoogleCodeExporter]

Hi,

i ran a test on my Windows box with Cygwin Git 2.1.1:

Cloning into 'dummy'...
Password for 'https://user@repo':
remote: Counting objects: 1382, done
remote: Finding sources: 100% (1382/1382)
remote: Getting sizes: 100% (317/317)
error: RPC failed; result=56, HTTP code = 200
fatal: The remote end hung up unexpectedly
fatal: protocol error: bad pack header

Original comment by d...@sigsegv.at on 10 Oct 2014 at 1:03

[GoogleCodeExporter]

And the other protocols?

Original comment by James.Mo...@gmail.com on 10 Oct 2014 at 4:51

[GoogleCodeExporter]

Hi,

same issue, e.g. the ssh:// protocol:

Cloning into 'dummy'...
Password authentication
Password:
remote: Counting objects: 1390, done
remote: Finding sources: 100% (1390/1390)
remote: Getting sizes: 100% (322/322)
Received disconnect from x.x.x.x: 2: User session has timed out idling after 
600000 ms.
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

The git:// protocol hangs as well but never returns, at least not in the 30 
minutes i was waiting :)

I tried a direct clone of the bare repository on the server bypassing Git:Blit, 
which worked as expected.

Br,
Tom.

Original comment by d...@sigsegv.at on 13 Oct 2014 at 9:03

[GoogleCodeExporter]

What is the size of this repo and how does that compare to the git.* settings 
in your gitblit.properties ?

http://stackoverflow.com/a/10027105/830200

Original comment by James.Mo...@gmail.com on 13 Oct 2014 at 12:16

[GoogleCodeExporter]

The size of the repo is roughly 1MB, Git:Blit calculates it to "1,018 KB".

I use these settings:

git.packedGitWindowSize = 8k
git.packedGitLimit = 100m
git.deltaBaseCacheLimit = 10m
git.packedGitOpenFiles = 128
git.streamFileThreshold = 50m

Original comment by d...@sigsegv.at on 13 Oct 2014 at 2:49

[GoogleCodeExporter]

Hi,

I upgraded to 1.6.1 tonight and the issue is gone.
I can successfully clone and fetch the broken repository again.

Br,
Tom.

Original comment by d...@sigsegv.at on 21 Oct 2014 at 5:21

[GoogleCodeExporter]

I'm very happy to hear that but I can't take the credit.  I suspect the newer 
JGit dependency is the reason for your success.

Original comment by James.Mo...@gmail.com on 21 Oct 2014 at 5:44

• Changed state: Fixed
• Added labels: Milestone-1.6.1