6

I have had a git server (git 1.7.1 on CentOS 6.5) running normally for a year,
and git clone/pull/push via https worked like a charm.
But today, when I try to push this file to my server, it fails with the following error message: 

Counting objects: 17, done.  
Delta compression using up to 4 threads.  
Compressing objects: 100% (7/7), done.  
Writing objects: 100% (7/7), 11.33 KiB | 0 bytes/s, done.  
Total 7 (delta 4), reused 0 (delta 0)  
fatal: protocol error: bad line length character: < HTM    
fatal: The remote end hung up unexpectedly  
fatal: The remote end hung up unexpectedly  
git did not exit cleanly (exit code 128) (13370 ms @ 2014/8/28 PM 01:54:39)

Now my local repo seems broken; I cannot push any file to my server.
I tried to run git rm docs.min.js but it still fails to push any file.
If I clone this repo to another working directory, though, I can push files normally.

I have tried several git clients including TortoiseGit on Windows 7, git on CentOS 6, git on Mac OSX 10.8, but all have the same problem.

Google searching indicates it is a server side problem, but my git server seems to be working fine. All other files, repositories can git clone/pull/push.

Running git-receive-pack gets the following result: 

00729cb8e722e189b90b7962bf94b91a8cefd8a819da refs/heads/master report-status delete-refs side-band-64k ofs-delta
003e9cb8e722e189b90b7962bf94b91a8cefd8a819da refs/tags/latest
003cbd3510b705ebc9def3afcac0a9bb59ba81a0960d refs/tags/prod
003be9c1bff213332f15892eb1a9c790c9737599b3fa refs/tags/v30
003b0411cb4c7be5f3d3bc4c80a70f10417bd34daed0 refs/tags/v31
003b6070e4869ccce82d0bc778821d748145a0575c2b refs/tags/v32
003b0d62d04331cd3067d93e1003ae8de56cee6601c1 refs/tags/v33
003bb40d0720f0bca2791c8b83b191e9faa673f25980 refs/tags/v34
003bab3cc6a4de19771625a9c30f9f75670745f61a7d refs/tags/v35
003b1f2e45a887653656e36f618839032265aae97989 refs/tags/v36
003b86423373fbecd056d63850e46bca22271bd73e09 refs/tags/v37
003bbd3510b705ebc9def3afcac0a9bb59ba81a0960d refs/tags/v38
003b9cb8e722e189b90b7962bf94b91a8cefd8a819da refs/tags/v39
0000

It hangs on 0000, and no error messages are shown.

Any idea?

yhan
  • 61
  • 2
  • 2
    related: http://stackoverflow.com/questions/8170436/git-remote-error-fatal-protocol-error-bad-line-length-character-unab So the problem is not with the file, it's with the repository sending bad protocol messages. – Malt Aug 28 '14 at 07:48
  • @Malt According to the related post, I run `git-receive-pack` and post the result above. But I still have no idea of what happens. Any suggestion? Thanks. – yhan Aug 28 '14 at 09:02
  • What do you use on the server side? The protocol error looks like the beginning of HTML. – musiKk Aug 28 '14 at 09:07
  • 1
    musiKk is right, " – Malt Aug 28 '14 at 09:20
  • @musiKk I use git + gitolite + nginx on CentOS. Do you mean this? – yhan Aug 28 '14 at 09:21
  • @yhan Yes. Do you access gitolite over SSH as it should be or somehow over HTTP? You can verify this with `git remote -v`. – musiKk Aug 28 '14 at 09:26
  • @musiKk I use https, both for fetch and push. – yhan Aug 28 '14 at 09:29
  • @yhan Hm, maybe it really is some HTML that gets sent erroneously. But that doesn't explain why it's only that file. Maybe your repository is corrupted? What does `git fsck` say? – musiKk Aug 28 '14 at 09:35
  • @yhan could you try capturing your attempted `git push` using wireshark? The HTML might provide some clues to what went wrong. – Malt Aug 28 '14 at 09:45
  • @Malt Won't do much good if it's HTTPS. – musiKk Aug 28 '14 at 09:46
  • @musiKk true, I missed that part. – Malt Aug 28 '14 at 09:48
  • @musiKk `git fsck` shows no error (actually, no message at all). @Malt packet sniffer doesn't work, because I use https... – yhan Aug 28 '14 at 09:57
  • @yhan Only thing I can think of now is looking at the log files of gitolite and nginx, probably configuring finer log levels. – musiKk Aug 28 '14 at 11:37
  • @musiKk I have checked nginx debug log and gitolite log, but no useful clues are found. Anyways, thanks for your help. :) – yhan Aug 29 '14 at 01:50
  • This problem disappears, but I don't know why. :( I didn't modify any configurations. I can push the file normally now. – yhan Sep 01 '14 at 10:21

1 Answers1

0

If you have access to gitolite over ssh you can verify with git-remote -v; and, if you don't, use http use the git fsck command.

unDeadHerbs
  • 1,306
  • 1
  • 11
  • 19
ehsan
  • 1