Объекты GIT Pack умерли от сигнала 10

Question

Я пытался перенести свои изменения сегодня в удаленный репозиторий, и я получаю следующую ошибку:

git push -u origin master
error: pack-objects died of signal 10

Вчера коммит и push работали нормально, никаких изменений в настройках не было, никто не фиксировал и не толкал в репозиторий, а коммит не очень большой, всего около 10 файлов

Я использую MacOS Sierra - git версии 2.9.3 (Apple Git-75), репозиторий - GitLab 8.13.5 (Git 2.7.4)

Весь репозиторий занимает всего 33 МБ, поэтому большие файлы не включены (даже в коммит). Я использую SSH для доступа к хранилищу.

git config pack.threads 1 не имел никакого эффекта.

Я также попытался клонировать удаленное в новое место, отредактировать один файл, зафиксировать, нажать, и это сработало, поэтому проблема должна быть в конкретном коммите.

Запуск git fsck приводит к той же ошибке:

git fsck
error: unable to open .git/objects/14: Interrupted system call
Checking object directories: 100% (256/256), done.
Bus error: 10

В чем проблема?

Answer 1

Эта ошибка:

error: unable to open .git/objects/14: Interrupted system call

довольно таинственно Это должен быть каталог и git fsck должен быть в состоянии открыть его, не прерывая. ¹ Вы можете запустить:

ls -ld .git/objects/14

чтобы убедиться, что это каталог, и если да, ls -l .git/objects/14 чтобы увидеть, что в нем (он должен содержать ноль или более файлов с хэш-идентификаторами в качестве имен ²).

SIGBUS указывает на какую-то внутреннюю ошибку в Git. Программы на C получают SIGBUS или SIGSEGV, когда они пытаются использовать адреса памяти, которые они никогда не предоставляли, или которые иным образом недействительны (см. Ошибка шины против ошибки сегментации и обратите внимание, что решение о том, какой сигнал доставлять, зависит как от ОС, так и от архитектуры -зависимый, так что Linux на ARM, MIPS или SPARC будет вести себя иначе, чем, например, в той же версии Linux на x86). Вполне вероятно, что все, что приводит к тому, что Git не может прочитать объекты, хранящиеся в хранилище, приводит к последующему падению Git, но Git - или, по крайней мере, git fsck - не должен падать из-за плохих хранилищ. С помощью git fsck в частности предполагается диагностировать что не так с плохим репозиторием. И в любом случае, получая EINTR при открытии каталога это необычно, по крайней мере.

Если файлы не являются локальными (обнаружены по сети), вы можете переместить их в локальное (на диске) хранилище и посмотреть, устранит ли это проблему. Это не столько "исправление" ошибки, сколько просто "ее избежание", но если этого достаточно....:-)

---

¹ Единственный очевидный путь, в котором это может быть не так, - это если файл или каталог хранятся не на локальном диске, а в сети, например на сервере AFP.

² Эти имена будут состоять всего из 38 символов, давая оставшуюся часть идентификатора хеша после удаления начального 14, 14 подразумевается тот факт, что они находятся в .git/objects/14/,