Клонирование не удается на большой глубине

У меня проблемы с клонированием репозитория FFmpeg. Используя алгоритм двоичного поиска, я думаю, что сузил проблему до определенной глубины. Обратите внимание на противоречивые результаты

$ git clone --depth 916 git://source.ffmpeg.org/ffmpeg
Cloning into 'ffmpeg'...
remote: Counting objects: 16737, done.
remote: Compressing objects: 100% (8454/8454), done.
remote: Total 16737 (delta 11293), reused 11481 (delta 8105)
Receiving objects: 100% (16737/16737), 11.32 MiB | 398.00 KiB/s, done.
Resolving deltas: 100% (11293/11293), done.

$ git clone --depth 916 git://source.ffmpeg.org/ffmpeg
Cloning into 'ffmpeg'...
remote: Counting objects: 16737, done.
remote: Compressing objects: 100% (8454/8454), done.
remote: Total 16737 (delta 11291), reused 11482 (delta 8105)
Receiving objects: 100% (16737/16737), 11.32 MiB | 390.00 KiB/s, done.
fatal: pack is corrupted (SHA1 mismatch)
fatal: index-pack failed

$ git clone --depth 916 git://source.ffmpeg.org/ffmpeg
Cloning into 'ffmpeg'...
remote: Counting objects: 16737, done.
remote: Compressing objects: 100% (8454/8454), done.
remote: Total 16737 (delta 11290), reused 11481 (delta 8105)
Receiving objects: 100% (16737/16737), 11.32 MiB | 401.00 KiB/s, done.
Resolving deltas: 100% (11290/11290), done.
fatal: missing blob object 'e893922133e1837d51077b07b6eb2ef3d5f269ec'
fatal: remote did not send all necessary objects

$ git clone --depth 916 git://source.ffmpeg.org/ffmpeg
Cloning into 'ffmpeg'...
remote: Counting objects: 16737, done.
remote: Compressing objects: 100% (8454/8454), done.
remote: Total 16737 (delta 11292), reused 11481 (delta 8105)
Receiving objects: 100% (16737/16737), 11.32 MiB | 394.00 KiB/s, done.
Resolving deltas: 100% (11292/11292), done.
Checking out files: 100% (3637/3637), done.

Как мне исправить эту проблему, чтобы я мог клонировать на этой и полной глубине?

$ git --version
git version 1.8.3.1

git git-clone
person Steven Penny    schedule 20.07.2013    source источник
comment
У меня не было проблем ни с git clone git://source.ffmpeg.org/ffmpeg, ни с git clone --depth 916 git://source.ffmpeg.org/ffmpeg. У вас все еще проблемы? Какая версия git? Какая ОС?   -  person Christopher    schedule 20.07.2013
comment
Неисправное оборудование для вас или для сервера? Второй и третий выглядят как коррупция. На самом деле не похоже, что количество коммитов является ключевым здесь, учитывая различные сбои. Попробуйте git clone -v, и, возможно, мы получим дополнительную информацию.   -  person Peter Lundgren    schedule 20.07.2013

Ответы (2)


arrow_upward
2
arrow_downward

В этом случае проблема вызвана использованием последней версии Cygwin (1.7.21) с последней версией Git от Cygwin Ports (1.8.3.1).

Обходной путь - использовать сборку Адама Динвуди.

wget tastycake.net/~adam/cygwin/x86/git/git-1.8.5.2-1.tar.xz
tar -x -C / -f git-1.8.5.2-1.tar.xz
person Steven Penny    schedule 21.07.2013
comment
У меня аналогичная установка (git из Cygwin Ports), но проблема возникает у меня только спорадически - повторный запуск с идентичной командной строкой обычно работает. - person mheyman; 07.01.2014

arrow_upward
1
arrow_downward

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

Я заметил, что каждый раз, когда я компилировал git из исходного кода под Cygwin и пытался проверить большое репо (~ 1 ГБ репо с дополнительным 1 ГБ подмодулей), я почти в 100% случаев терпел неудачу с этой ошибкой. Однако это всегда работало, если я использовал предварительно скомпилированный git из Cygwin setup.exe. Даже если бы я сам скомпилировал ту же самую версию (1.7.9), моя компиляция не удалась бы, и их компиляция сработала. Я сравнил objdump с обоими файлами .exe, и единственное существенное отличие заключалось в том, что мой .exe использовал cygcrypto-1.0.0.dll, а они использовали cygcrypto-0.9.8.dll.

Итак, я сделал резервную копию cygcrypto-1.0.0.dll и сделал символьную ссылку на cygcrypto-1.0.0.dll на 0.9.8. Теперь я успешно проверил репо и подмодули 3 раза подряд (по сравнению с предыдущим почти 100% -ным уровнем отказов). Я не могу гарантировать, что это решит проблему на 100%, но это выглядит очень многообещающим.

Я предполагаю, что если вы используете Git, вы, вероятно, имеете представление о возможных проблемах с символической привязкой новой версии DLL к старой версии. Используйте на свой риск.

(Бонусные баллы, если кто-то отвечает, как заставить мою сборку git напрямую связываться с 0.9.8, поэтому мне не нужно символизировать DLL. Я использую cygwin только для Git и недостаточно хорошо знаю систему сборки, чтобы знать, как для ссылки на старые версии)

person Chris O'Bryan    schedule 10.01.2014