Ошибка Git push: не удается отправить определенный файл в удаленное репо

У меня был сервер git (git 1.7.1 на CentOS 6.5), который работал нормально в течение года,
и git clone/pull/push через https работал как шарм.
Но сегодня, когда я пытаюсь нажать этот файл на мой сервер, происходит сбой со следующим сообщением об ошибке:

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)

Теперь мой локальный репо кажется сломанным; Я не могу отправить какой-либо файл на свой сервер.
Я попытался запустить git rm docs.min.js, но он по-прежнему не может отправить ни один файл.
Однако, если я клонирую этот репозиторий в другой рабочий каталог, я могу отправить файлы в обычном режиме.

Я пробовал несколько клиентов git, включая TortoiseGit в Windows 7, git в CentOS 6, git в Mac OSX 10.8, но у всех одна и та же проблема.

Поиск в Google указывает, что это проблема на стороне сервера, но мой сервер git работает нормально. Все остальные файлы, репозитории могут git clone/pull/push.

Выполнение git-receive-pack дает следующий результат:

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

Зависает на 0000, и никаких сообщений об ошибках не показывает.

Любая идея?


git git-push
person yhan    schedule 28.08.2014    source источник
comment
связанные: stackoverflow.com/questions/8170436/ Таким образом, проблема не в файле, а в том, что репозиторий отправляет неверные сообщения протокола.   -  person Malt    schedule 28.08.2014
comment
@Malt Согласно соответствующему сообщению, я запускаю git-receive-pack и публикую результат выше. Но я до сих пор понятия не имею, что происходит. Любое предложение? Спасибо.   -  person yhan    schedule 28.08.2014
comment
Что вы используете на стороне сервера? Ошибка протокола выглядит как начало HTML.   -  person musiKk    schedule 28.08.2014
comment
musiKk прав, ‹HTM выглядит как начало HTML-ответа. Будучи сетевым парнем (а не большим экспертом по git), я бы попытался перехватить эту транзакцию с помощью wireshark или аналогичного анализатора пакетов. Посмотрите, что отправляется по линии. Вероятно, это страница с ошибкой сервера...   -  person Malt    schedule 28.08.2014
comment
@musiKk Я использую git + gitolite + nginx на CentOS. Вы имеете в виду это?   -  person yhan    schedule 28.08.2014
comment
@yhan Да. Вы получаете доступ к gitolite через SSH, как это должно быть, или как-то через HTTP? Вы можете проверить это с помощью git remote -v.   -  person musiKk    schedule 28.08.2014
comment
@musiKk Я использую https как для извлечения, так и для отправки.   -  person yhan    schedule 28.08.2014
comment
@yhan Хм, может быть, это действительно какой-то HTML, который отправляется ошибочно. Но это не объясняет, почему это только этот файл. Может быть, ваш репозиторий поврежден? Что говорит git fsck?   -  person musiKk    schedule 28.08.2014
comment
@yhan, не могли бы вы попробовать зафиксировать попытку git push с помощью wireshark? HTML может дать некоторые подсказки, что пошло не так.   -  person Malt    schedule 28.08.2014
comment
@Malt Не очень хорошо, если это HTTPS.   -  person musiKk    schedule 28.08.2014
comment
@musiKk правда, я пропустил эту часть.   -  person Malt    schedule 28.08.2014
comment
@musiKk git fsck не показывает ошибки (на самом деле вообще никакого сообщения). Сниффер пакетов @Malt не работает, потому что я использую https...   -  person yhan    schedule 28.08.2014
comment
@yhan Единственное, о чем я сейчас могу думать, это просмотр файлов журналов gitolite и nginx, возможно, для настройки более тонких уровней журналов.   -  person musiKk    schedule 28.08.2014
comment
@musiKk Я проверил журнал отладки nginx и журнал gitolite, но полезных подсказок не нашел. В любом случае, спасибо за вашу помощь. :)   -  person yhan    schedule 29.08.2014
comment
Эта проблема исчезает, но я не знаю, почему. :( Я не менял никаких настроек. Теперь я могу нормально отправить файл.   -  person yhan    schedule 01.09.2014