сбой выборки git из-за сбоя pack-object

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

    $ git fetch upstream
    remote: Counting objects: 11901, done.
    remote: aborting due to possible repository corruption on the remote side.
    error: pack-objects died of signal 9
    error: git upload-pack: git-pack-objects died with error.
    fatal: git upload-pack: aborting due to possible repository corruption on the re
    mote side.
    fatal: protocol error: bad pack header

Я понимаю, что он терпит неудачу из-за наличия огромных файлов в репозитории( который у нас есть) , но почему он не терпит неудачу, когда я клонирую тот же репозиторий? Потому что я могу успешно клонировать репозиторий. Разве одни и те же объекты не должны быть упакованы во время запроса на клонирование?

6
git git-clone git-fetch

2 ответов

чтобы немного расширить на VonC это...

во-первых, это может помочь отметить, что signal 9 относится к SIGKILL и имеет тенденцию возникать, потому что рассматриваемый пульт является хостом Linux, и процесс уничтожается Linux "убийца ООТ" (хотя некоторые системы, отличные от Linux, ведут себя аналогично).

Далее, давайте поговорим об объектах и пакетных файлах. Git "объект" является одним из четырех типов элементов, которые находятся в репозитории git: a "blob "(файл);" дерево "(список Blob, их режимы и их имена, хранящиеся в каталоге: т. е. то, что станет каталогом или папкой при распаковке фиксации);" фиксация "(которая дает автор фиксации, сообщение и дерево верхнего уровня среди других данных); и" тег " (аннотированный тег). Объекты могут храниться как "свободные объекты", причем один объект в файле сам по себе; но они могут занимать много места на диске, поэтому они могут быть вместо этого "упакованы", много объектов в один файл с дополнительными добавлено сжатие.

создание пакета из большого количества свободных объектов, делая это сжатие, является (или, по крайней мере, может быть) cpu - и memory-intensive операция. Объем памяти зависит от числа объектов и их размеров: большие файлы занимают больше памяти. Многие большие файлы занимают много памяти.

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

С другой стороны, git fetch пытается, если это возможно, избежать отправки большого количества данных, которые клиент уже имеет. Используя "умный" протокол, клиент и сервер вступают в своего рода разговор, который вы можете думать о чем-то вроде этого:

    12

    это может зависеть от протокола, но Documentation/technical/pack-heuristics.txt указывает на первое различие между clone и fetch.

    в другую сторону, принеси,git-fetch-pack и git-clone-pack вызывает git-upload-pack на другом конце (через ssh или разговаривая с демоном).

    есть два случая:

    • clone-pack и fetch-pack С -k сохранит загруженный packfile без расширения, поэтому мы не используем тонкую передачу пакета.
    • в противном случае сгенерированный пакет будет иметь delta без базового объекта в том же пакете.

    но fetch-pack без -k взорвет полученный пакет на отдельные объекты, поэтому мы автоматически спрашиваем upload-pack to дайте нам тонкую пачку если upload-pack поддерживает его.

    так что в плане протоколов,Documentation/technical/pack-protocol.txt иллюстрирует, что выборка может вернуться много данные, чем a git клон.

    3