Получение фатального исхода: объект поврежден при отправке в удаленное репо

У меня есть сервер с установленным Gitolite для размещения моих репозиториев. Вчера я создал новое репо, а сегодня, когда я попытался отправить больше коммитов на сервер, я получаю:

fatal: object 86eeaa0c5a154ff3df34d6a43669930b9c6c7f59 is corrupted
error: unpack failed: unpack-objects abnormal exit
error: failed to push some refs to

Поскольку репозиторий довольно новый, меня не слишком беспокоила потеря предыдущих коммитов, поэтому я удалил как локальный, так и удаленный репо, но все равно получаю ту же ошибку.

Как я уже сказал, меня не слишком беспокоит сохранение моей истории коммитов, я просто хотел бы, чтобы она снова заработала!


git gitolite
person simon    schedule 24.05.2012    source источник
comment
Вы создали свой новый репозиторий, объявив его в файле gitolite.conf локального клона репозитория gitolite-admin и отправив этот репозиторий gitolite-admin обратно на сервер gitolite, верно? (см. sitaramc.github.com/gitolite/repos.html). Вы не git init прямо себе на сервер gitolite, я полагаю?   -  person VonC    schedule 24.05.2012
comment
А какая у вас версия гитолита? Вы сделали несколько команд 'gl-xxx' (например, gl-setup)? То есть Гитолайт В2. Или вы сделали gitolite install (gitolite V3 или g3)   -  person VonC    schedule 24.05.2012
comment
Да, я объявил новое репо в gitolite.conf на моей локальной машине, а затем отправил его обратно на сервер gitolite, затем я клонировал это репо на свою машину, добавил файлы, зафиксировал и отправил обратно на сервер. Это работает нормально, только когда я иду на сервер во второй раз. Я использую версию g3.   -  person simon    schedule 24.05.2012
comment
@VonC репозиторий, который у меня есть, работает нормально, я могу клонировать и отправлять коммиты.   -  person simon    schedule 24.05.2012
comment
И первое репо (тот, с проблемой при втором нажатии), можете ли вы клонировать его прямо на сервер gitolite (то есть локальный клон /path/to/repo) и посмотреть, сможете ли вы вернуть его обратно?   -  person VonC    schedule 24.05.2012
comment
@VonC Нет, я получаю fatal: object 94b3887fa96f1a40e77f9a0cf9f566acb1e995a3 is corrupted, поэтому я предполагаю, что что-то не так с созданием нового репо?   -  person simon    schedule 24.05.2012
comment
да, если можете: попробуйте повторить весь процесс создания и посмотрите, повторяется ли эта проблема. (добавьте еще одно репо в gitolite.conf и снова нажмите на gitolite-admin   -  person VonC    schedule 24.05.2012
comment
@VonC Хорошо, я не замечал этого раньше, но когда я создаю новый репо, я получаю следующую ошибку remote: line 1 too long: command="/home/git/gitolite/src/gitolite... remote: FATAL: fingerprinting failed for /tmp/Cdug9Itivq Но он создает репо в /home/git/repositories   -  person simon    schedule 24.05.2012
comment
Так что это нужно как-то решать. Можете ли вы попытаться создать ключ ssh, как в stackoverflow. com/questions/10736964/gitolite-admin-clone-issue/ ? И использовать его для клонирования / отправки репозитория gitolite-admin?   -  person VonC    schedule 24.05.2012
comment
возможный дубликат журнала Git: фатальный объект [sha1] поврежден   -  person CharlesB    schedule 24.05.2012

Ответы (1)


arrow_upward
5
arrow_downward

Как видно из комментариев, любое дополнительное репо имеет проблему во время его создания (т. е. при возврате репозитория gitolite-admin с файлом gitolite.conf, объявляющим новое репо)

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

remote: line 1 too long: command="/home/git/gitolite/src/gitolite... 
remote: FATAL: fingerprinting failed for /tmp/Cdug9Itivq

Но он создает репо в /home/git/repositories

Эта операция выполняется в посткомпиляционном триггере с именем ssh-authkeys:

sub fp_file {
    return $selinux++ if $selinux; # return a unique "fingerprint" to prevent noise
    my $f = shift;
    my $fp = `ssh-keygen -l -f '$f'`;
    chomp($fp);
    _die "fingerprinting failed for '$f'" unless $fp =~ /([0-9a-f][0-9a-f](:[0-9a-f][0-9a-f])+)/;
    $fp = $1;
    return $fp;
}

Это означает, что ssh-keygen -l -f <path_to_public_key.pub> не соответствует правильному шаблону, как показано в разделе "самостоятельное управление ключами".

Убедитесь, что ваш ключ сгенерирован следующим образом:

ssh-keygen -t rsa -f "${H}/.ssh/git" -C "Gitolite Admin access (not interactive)" -q -P ""

Обновление за апрель 2015 г.:

Как упоминалось starfry в "Gitolite — удаленный: FATAL: не удалось снять отпечатки пальцев для 'keydir/'":

В OpenSSH версии 6.8 произошло изменение формата отпечатка ключа:

Добавьте параметр FingerprintHash к ssh(1) и sshd(8) и эквивалентные флаги командной строки к другим инструментам для управления алгоритмом, используемым для отпечатков ключей. Значение по умолчанию меняется с MD5 на SHA256 и формат с шестнадцатеричного на base64.

Теперь к отпечаткам пальцев добавляется хэш-алгоритм.
Пример нового формата:

SHA256:mVPwvezndPv/ARoIadVY98vAC0g+P/5633yTC4d/wXE

Обратите внимание, что визуальные ключи хоста также будут отличаться.

последний git checkout gitolite знает с 18 марта 2015 года об этом новом формат.

person VonC    schedule 24.05.2012
comment
Спасибо за еще один очень информативный ответ! Я создал новый ключ, как было предложено. Что мне теперь делать с ключом git.pub? - person simon; 25.05.2012
comment
@simon: используйте этот ключ, как описано в sitaramc.github.com/gitolite/setup.html (поэтому с id.pub, переименованным в «общее имя учетной записи», предназначенное для администрирования gitolite ssh: см. stackoverflow.com/questions/10736964/gitolite-admin-clone-issue/ для иллюстрации), чтобы снова инициировать репозиторий gitolite-admin, клонировать его, объявить новый репозитории, клонируйте их и посмотрите, сохраняется ли проблема. - person VonC; 25.05.2012
comment
Версия отпечатка изменена с OpensSSH 6.8 См. этот ответ - person starfry; 20.04.2015
comment
@starfry Понятно. Я также включил ваш ответ здесь, для большей наглядности. - person VonC; 20.04.2015