Error git upload pack git pack objects died with error

Problem

Git commands don’t complete successfully.

The following appears in the command console output:

error: RPC failed; HTTP 500 curl 22 The requested URL returned error: 500 Internal Server Error

The following appears in the atlassian-bitbucket.log

ERROR [http-nio-7990-exec-52] <username> @1WU14K3x805x122891x1 193.39.66.214 "POST /scm/<project_key>/<repository_slug>.git/git-upload-pack HTTP/1.1" c.a.s.i.s.g.p.h.GitSmartExitHandler <project_key>/<repository_slug>[10]: Read request from 193.39.66.214 failed: com.atlassian.utils.process.ProcessException: Non-zero exit code: 1
The following was written to stderr:
error: git upload-pack: git-pack-objects died with error.
fatal: git upload-pack: aborting due to possible repository corruption on the remote side.

Cause

There may be several causes for this problem:

Cause #1 — Corrupted Git repository

The database has become corrupted (e.g. as a consequence of a filesystem corruption).

Note: cloning the repository directly on the filesystem (without using Bitbucket Server) may still succeed since a Git clone does not run any additional checks and assumes that the repository is in a consistent state.

Workaround

Try to run the following commands to see if they resolve the problem:

• Stop Bitbucket Server
• Copy the $BITBUCKET_HOME/shared/data/repositories/<repository_id> folder. This is to make sure that a backup of the entire repository is available.

• Run the following commands from the $BITBUCKET_HOME/shared/data/repositories/<repository_id> path:

  git fsck --no-dangling
  git repack -adfln --keep-unreachable --depth=20 --window=200

• Start Bitbucket Server

If the steps above don’t resolve the problem, the repository may be not recoverable. In this case, the situation can be resolved by restoring a backup generated prior to the corruption.

To expand a bit on VonC’s answer…

First, it may help to note that signal 9 refers to SIGKILL and tends to occur because the remote in question is a Linux host and the process is being destroyed by the Linux «OOM killer» (although some non-Linux systems behave similarly).

Next, let’s talk about objects and pack-files. A git «object» is one of the four types of items that are found in a git repository: a «blob» (a file); a «tree» (a list of blobs, their modes, and their names-as-stored-in-a-directory: i.e., what will become a directory or folder on when a commit is unpacked); a «commit» (which gives the commit author, message, and top level tree among other data); and a «tag» (an annotated tag). Objects can be stored as «loose objects», with one object in a file all by itself; but these can take up a lot of disk space, so they can instead be «packed», many objects into one file with extra compression added.

Making a pack out of a lot of loose objects, doing this compression, is (or at least can be) a cpu- and memory-intensive operation. The amount of memory required depends on the number of objects and their underlying sizes: large files take more memory. Many large files take a whole lot of memory.

Next, as VonC noted, git clone skips the attempt to use «thin» packs (well, normally anyway). This means the server just delivers the pack-files it already has. This is a «memory-cheap» operation: the files already exist and the server need only deliver them.

On the other hand, git fetch tries, if it can, to avoid sending a lot of data that the client already has. Using a «smart» protocol, the client and server engage in a sort of conversation, which you can think of as going something like this:

• «I have object A, which needs B and C; do you have B and C? I also have D, E, and F.»
• «I have B but I need C, and I have D and E; please send me A, C, and F.»

Thus informed, the server extracts the «interesting» / «wanted» objects out of the original packs, and then attempts to compress them into a new (but «thin») pack. This means the server will invoke git-pack-objects.

If the server is low on memory (with «low» being relative to the amount that git-pack-objects is going to need), it’s likely to invoke the «OOM killer». Since git-pack-objects is memory-intensive, that process is a likely candidate for the «OOM killer» to kill. You then see, on your client end, a message about git-pack-objects dying from signal 9 (SIGKILL).

(Of course it’s possible the server’s OOM killer kills something else entirely, such as the bug database server. )

Bitbucket Support

Knowledge base

Products

Jira Software

Project and issue tracking

Jira Service Management

Service management and customer support

Jira Work Management

Manage any business project

Confluence

Bitbucket

Git code management

Resources

Documentation

Usage and admin help

Answers, support, and inspiration

Suggestions and bugs

Feature suggestions and bug reports

Marketplace

Billing and licensing

Frequently asked questions

Viewport

Confluence

Git operations fail due to «git-pack-objects died with error»

Related content

Still need help?

The Atlassian Community is here for you.

Platform notice: Server and Data Center only. This article only applies to Atlassian products on the server and data center platforms .

Problem

Git commands don’t complete successfully.

The following appears in the command console output:

The following appears in the atlassian-bitbucket.log

Cause

There may be several causes for this problem:

Cause #1 — Corrupted Git repository

The database has become corrupted (e.g. as a consequence of a filesystem corruption).

Note: cloning the repository directly on the filesystem (without using Bitbucket Server) may still succeed since a Git clone does not run any additional checks and assumes that the repository is in a consistent state.

Workaround

Try to run the following commands to see if they resolve the problem:

• Stop Bitbucket Server
• Copy the $BITBUCKET_HOME/shared/data/repositories/ folder. This is to make sure that a backup of the entire repository is available.

Run the following commands from the $BITBUCKET_HOME/shared/data/repositories/ path:

If the steps above don’t resolve the problem, the repository may be not recoverable. In this case, the situation can be resolved by restoring a backup generated prior to the corruption.

Источник

Git Не удалось выполнить клонирование с «index-pack»?

Итак, я создал удаленное репо, которое не было голым (потому что мне нужно, чтобы redmine мог его прочитать), и он должен быть разделен с группой (так что git init —shared = group). Я смог нажать на дистанционное репо, и теперь я пытаюсь клонировать его.

Если я клонирую его по сети, я получаю следующее:

Я могу клонировать его локально без проблем, и я запускал «git fsck», который сообщает только о некоторых висячих деревьях/блоках, которые, как я понимаю, не являются проблемой. Что может быть причиной этого? Я все еще могу извлечь из него, просто не клонировать. Я должен отметить, что удаленная версия git равна 1.5.6.5, а локальная — 1.6.0.4

Я попытался клонировать мою локальную копию репо, удалив папку .git и нажав на новое репо, затем клонируя новое репо, и я получаю ту же ошибку, что заставляет меня думать, что это файл в repo, что приводит к сбою git -upload-pack.

Изменить: У меня есть несколько двоичных файлов окон в репо, потому что я только что построил модули python, а затем закрепил их там, чтобы всем остальным не приходилось их создавать. Если я удалю двоичные файлы Windows и нажимаю на новое репо, я могу снова клонировать, возможно, это дает ключ. Попытка сузить точно, какой файл вызывает проблему сейчас.

ОТВЕТЫ

Ответ 1

Как я решил эту проблему: My git daemon работает в Windows, а клиенты находятся на других компьютерах.

Я нашел обходное решение (но оно будет работать только в окнах).

Запустите демон git с подробным из cmd.exe:

Не тестируется, если он работает непосредственно в git bash. Может быть, будет.

Затем (перед запуском любого клона, pull, fetch. ) выберите текст в окне (обратите внимание: «Режим быстрого редактирования» должен быть включен (можно найти в: cmd.exe → Свойства (щелкните верхний левый угол вашего окна cmd) → Параметры редактирования)), в котором запускается демон git. Это предотвратит его печать любых последующих сообщений в этом окне.

Когда выходной поток демона git заблокирован таким образом, ошибка не выполняется

Ответ 2

У меня та же проблема, что и вы; сообщение об ошибке при клонировании i:

В моем случае причина в том, что размер моего репозитория (200M) больше, чем моя серверная память git (128M). Когда я клонирую с сервера git , я использую команду top на моем сервере, которая показывает, что использование памяти скоро превысит 128M.

Когда я использую другой сервер с памятью 4G, git clone все в порядке. Вы также можете попробовать добавить дополнительное пространство подкачки к вашему серверу.

Ответ 3

Спрашивает ли «git gc»?

Ответ 4

У меня была та же проблема. Мое предположение также заключалось в том, что это связано с тем, что я использую режим text/CRLF для созданных файлов. И действительно, после переключения CygWin в UNIX/двоичный режим новой строки все работает нормально.

Кстати, самый простой способ переключить режим файла — редактировать /etc/fstab для переключения с

none/cygdrive cygdrive text, posix = 0, user 0 0

none/cygdrive cygdrive binary, posix = 0, пользователь 0 0

Ответ 5

У меня также были проблемы с cygwin git, ошибка: fatal: index-pack failed ,

Мне удалось решить эту проблему, создав mount для моих проектов и установив его в двоичный режим. поскольку мой /c установлен в текстовый режим.

Добавьте cygwin в /etc/fstab :

запустите mount -a , чтобы смонтировать все диски.

Вам нужно быть в /projects для работы с cygwin git , /c/work/Projects не удастся.

Не уверен, что это сработает для вас.

Ответ 6

Используйте переменную среды GIT_TRACE , чтобы получить вывод отладки. Установите для параметра «1» значение «stderr» или абсолютный путь к трассировке в файл.

Ответ 7

Я обновил свой клиентский компьютер git до той же версии, что и сервер, и это исправлено для меня.

Ответ 8

У меня та же проблема, и я бы изменил свои конфигурации git, и это нормально работает:

git config —global pack.packSizeLimit 50m
git config —global pack.windowMemory 50m
git config —global core.compression 9

Ответ 9

Проблема git-daemon, кажется, была решена в v2.17.0 (проверено с неработающим v2.16.2.1). Т.е. обходной путь выбора текста в консоли для «блокировки выходного буфера» больше не требуется.

• Ассорти исправления для «git daemon». (объединить ed15e58efe jk/daemon-fixes позже в maint).

Ответ 10

У меня была эта проблема или близкая к ней, но я не видел решения моего дела ни в одной из этих тем.

В моем случае проблема была в брандмауэре. Клонирование небольших репозиториев работало в любом случае, но большие не удавались. Так что, если больше ничего не помогает, настройки брандмауэра стоит проверить.

Ответ 11

Я столкнулся с этой проблемой, клонируя репозиторий github с github.com, запустив git 2.13 на SLES 12 SP3. Пробовал обновлять git до последней версии (v2.21 в то время), но это не помогло решить проблему. Пробовал настраивать параметры git config, предлагал и многие другие варианты, но не повезло.

В конце концов, я сделал это вручную.

• создал каталог вручную.. mkdir somedir
• Запустил git init чтобы настроить каталог для GIT.
• Вручную добавили репозиторий github в качестве источника git remote add origin http://github.com/git/git
• Побежал git fetch чтобы взять пачку. Эта задача .git/objects/pack/tmp_pack_XXXXXX ошибкой, но оставила пакет «извлечен, но плох» в .git/objects/pack/tmp_pack_XXXXXX
• подержанный cat.git/objects/pack/tmp_pack_XXXXXX | git unpack-objects -r cat.git/objects/pack/tmp_pack_XXXXXX | git unpack-objects -r чтобы извлечь все допустимые объекты.
• Запустил git fetch снова, чтобы пропустить что-то (например, ветки и теги) из предыдущих попыток. Никакая упаковка/объекты не нужны, потому что все они были распакованы.
• Наконец, git checkout master , чтобы HEAD указывал на что-то реальное.

Я не уверен, что это необходимо для меня, но я бы порекомендовал git fsck и git gc после этого, что также вызовет git для воссоздания пакетов/индексов.

Ответ 12

Я решаю эту проблему, исправляя разрешение папки:

Источник

Как клонировать поврежденный репозиторий git

Ошибка, которую я получаю при попытке клонировать репо:

Есть ли способ обойти это?

У вас есть административный доступ к repo.xx.xx.com ? Есть резервные копии? Или другие (чистые) клоны?

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

Я бы, наверное, начал с резервного копирования того, что у вас есть, а затем запустил git gc на сервере.

У меня ничего нет (впервые клонирую это репо)

Я думаю, что он может быть недавно поврежден, есть ли способ клонировать репо на определенную дату?

Я интерпретировал «У меня есть доступ к репозиторию» как ответ «да» на «У вас есть административный доступ к repo.xx.xx.com ?» Так это нет? Самый простой способ клонировать «более раннюю версию» — это если есть тег или ветка, указывающая на более старую фиксацию. Существует ли какой-либо из них?

о, нет административного доступа. Я не знаю, какие теги или ветки содержит этот репозиторий.

Попробуйте побегать git ls-remote git@repo.xx.xx.com:project.git . Это должно показать вам все доступные ссылки. Посмотрите, не выглядит ли один из них хорошим кандидатом.

Кроме того, вы можете связаться с тем, кто админит сервер? У них могут быть резервные копии или иным образом иметь возможность восстановить репо.

@Chris, круто, я вижу несколько ссылок, это глупый вопрос, но как мне использовать эти ссылки?

Посмотрите, поможет ли вам git clone —single-branch —branch refname git@repo.xx.xx.com:project.git .

круто одна из веток сработала! теперь, чтобы выяснить, почему master ветка не.

Здорово! Я добавил ответ, резюмирующий то, что мы сделали.

Без административного доступа к серверу или чистой копии вы мало что можете сделать. Однако, поскольку вы считаете, что повреждение влияет на недавнюю фиксацию, вы можете попробовать клонировать другую ветку и посмотреть, сработает ли это.

Во-первых, давайте посмотрим, что доступно для клонирования:

Это должно дать вам список ссылок, доступных на сервере. Как только вы найдете кандидата, попробуйте клонировать его с помощью

Другие вопросы по теме

Похожие вопросы

Находите ответы на сложные технические вопросы по программированию, с которыми сталкиваются инженеры по всему миру в своей ежедневной практике на сайте RedDeveloper.

Источник

git clone завершается с ошибкой «index-pack»?

Поэтому я создал удаленное репо, которое не пустое (потому что мне нужен redmine, чтобы иметь возможность его читать), и оно настроено для общего доступа к группе (так что git init —shared=group). Я смог подтолкнуть к удаленному репо, и теперь я пытаюсь его клонировать.

Если я клонирую это по сети, я получаю это:

Я могу клонировать его локально без проблем, и я запустил «git fsck», который сообщает только о некоторых висячих деревьях / каплях, которые, как я понимаю, не являются проблемой. Что может быть причиной этого? Я все еще могу вытащить его, но не клонировать. Я должен отметить, что удаленная версия git- 1.5.6.5, а локальная — 1.6.0.4.

Я попытался клонировать свою локальную копию репо, вычистить папку.git и нажать на новое репо, затем клонировать новое репо, и я получил ту же ошибку, которая заставляет меня поверить, что это может быть файл в репо, который вызывает git-upload-pack не работает.

Редактировать: У меня есть несколько оконных бинарных файлов в репозитории, потому что я просто собрал модули python, а затем вставил их туда, чтобы всем остальным тоже не пришлось их создавать. Если я удалю бинарные файлы Windows и перейду к новому репо, я смогу снова клонировать, возможно, это даст подсказку. Попытка точно определить, какой файл вызывает проблему сейчас.

14 ответов

Я решил эту проблему так: мой демон git работает на Windows, а клиенты на других компьютерах.

Я нашел обходной путь (но он будет работать только на окнах).

Запустите git daemon с подробной версией cmd.exe:

Не проверено, работает ли оно непосредственно в git bash. Может быть, так и будет.

Затем (перед запуском любого клонирования, извлечения, извлечения. ) выделите текст в окне (примечание: «Режим быстрого редактирования» должен быть включен (его можно найти в: cmd.exe -> Свойства (щелкните в левом верхнем углу). угол вашего окна cmd) -> Edit Options)), в котором работает git daemon. Это помешает ему напечатать любые дальнейшие сообщения в этом окне.

Когда выходной поток git daemon блокируется таким образом, ошибка не возникает

Источник

Git Не удалось выполнить клонирование с «index-pack»?

Итак, я создал удаленное репо, которое не было голым (потому что мне нужно, чтобы redmine мог его прочитать), и он должен быть разделен с группой (так что git init —shared = group). Я смог нажать на дистанционное репо, и теперь я пытаюсь клонировать его.

Если я клонирую его по сети, я получаю следующее:

Я могу клонировать его локально без проблем, и я запускал «git fsck», который сообщает только о некоторых висячих деревьях/блоках, которые, как я понимаю, не являются проблемой. Что может быть причиной этого? Я все еще могу извлечь из него, просто не клонировать. Я должен отметить, что удаленная версия git равна 1.5.6.5, а локальная — 1.6.0.4

Я попытался клонировать мою локальную копию репо, удалив папку .git и нажав на новое репо, затем клонируя новое репо, и я получаю ту же ошибку, что заставляет меня думать, что это файл в repo, что приводит к сбою git -upload-pack.

Изменить: У меня есть несколько двоичных файлов окон в репо, потому что я только что построил модули python, а затем закрепил их там, чтобы всем остальным не приходилось их создавать. Если я удалю двоичные файлы Windows и нажимаю на новое репо, я могу снова клонировать, возможно, это дает ключ. Попытка сузить точно, какой файл вызывает проблему сейчас.

ОТВЕТЫ

Ответ 1

Как я решил эту проблему: My git daemon работает в Windows, а клиенты находятся на других компьютерах.

Я нашел обходное решение (но оно будет работать только в окнах).

Запустите демон git с подробным из cmd.exe:

Не тестируется, если он работает непосредственно в git bash. Может быть, будет.

Затем (перед запуском любого клона, pull, fetch. ) выберите текст в окне (обратите внимание: «Режим быстрого редактирования» должен быть включен (можно найти в: cmd.exe → Свойства (щелкните верхний левый угол вашего окна cmd) → Параметры редактирования)), в котором запускается демон git. Это предотвратит его печать любых последующих сообщений в этом окне.

Когда выходной поток демона git заблокирован таким образом, ошибка не выполняется

Ответ 2

У меня та же проблема, что и вы; сообщение об ошибке при клонировании i:

В моем случае причина в том, что размер моего репозитория (200M) больше, чем моя серверная память git (128M). Когда я клонирую с сервера git , я использую команду top на моем сервере, которая показывает, что использование памяти скоро превысит 128M.

Когда я использую другой сервер с памятью 4G, git clone все в порядке. Вы также можете попробовать добавить дополнительное пространство подкачки к вашему серверу.

Ответ 3

Спрашивает ли «git gc»?

Ответ 4

У меня была та же проблема. Мое предположение также заключалось в том, что это связано с тем, что я использую режим text/CRLF для созданных файлов. И действительно, после переключения CygWin в UNIX/двоичный режим новой строки все работает нормально.

Кстати, самый простой способ переключить режим файла — редактировать /etc/fstab для переключения с

none/cygdrive cygdrive text, posix = 0, user 0 0

none/cygdrive cygdrive binary, posix = 0, пользователь 0 0

Ответ 5

У меня также были проблемы с cygwin git, ошибка: fatal: index-pack failed ,

Мне удалось решить эту проблему, создав mount для моих проектов и установив его в двоичный режим. поскольку мой /c установлен в текстовый режим.

Добавьте cygwin в /etc/fstab :

запустите mount -a , чтобы смонтировать все диски.

Вам нужно быть в /projects для работы с cygwin git , /c/work/Projects не удастся.

Не уверен, что это сработает для вас.

Ответ 6

Используйте переменную среды GIT_TRACE , чтобы получить вывод отладки. Установите для параметра «1» значение «stderr» или абсолютный путь к трассировке в файл.

Ответ 7

Я обновил свой клиентский компьютер git до той же версии, что и сервер, и это исправлено для меня.

Ответ 8

У меня та же проблема, и я бы изменил свои конфигурации git, и это нормально работает:

git config —global pack.packSizeLimit 50m
git config —global pack.windowMemory 50m
git config —global core.compression 9

Ответ 9

Проблема git-daemon, кажется, была решена в v2.17.0 (проверено с неработающим v2.16.2.1). Т.е. обходной путь выбора текста в консоли для «блокировки выходного буфера» больше не требуется.

• Ассорти исправления для «git daemon». (объединить ed15e58efe jk/daemon-fixes позже в maint).

Ответ 10

У меня была эта проблема или близкая к ней, но я не видел решения моего дела ни в одной из этих тем.

В моем случае проблема была в брандмауэре. Клонирование небольших репозиториев работало в любом случае, но большие не удавались. Так что, если больше ничего не помогает, настройки брандмауэра стоит проверить.

Ответ 11

Я столкнулся с этой проблемой, клонируя репозиторий github с github.com, запустив git 2.13 на SLES 12 SP3. Пробовал обновлять git до последней версии (v2.21 в то время), но это не помогло решить проблему. Пробовал настраивать параметры git config, предлагал и многие другие варианты, но не повезло.

В конце концов, я сделал это вручную.

• создал каталог вручную.. mkdir somedir
• Запустил git init чтобы настроить каталог для GIT.
• Вручную добавили репозиторий github в качестве источника git remote add origin http://github.com/git/git
• Побежал git fetch чтобы взять пачку. Эта задача .git/objects/pack/tmp_pack_XXXXXX ошибкой, но оставила пакет «извлечен, но плох» в .git/objects/pack/tmp_pack_XXXXXX
• подержанный cat.git/objects/pack/tmp_pack_XXXXXX | git unpack-objects -r cat.git/objects/pack/tmp_pack_XXXXXX | git unpack-objects -r чтобы извлечь все допустимые объекты.
• Запустил git fetch снова, чтобы пропустить что-то (например, ветки и теги) из предыдущих попыток. Никакая упаковка/объекты не нужны, потому что все они были распакованы.
• Наконец, git checkout master , чтобы HEAD указывал на что-то реальное.

Я не уверен, что это необходимо для меня, но я бы порекомендовал git fsck и git gc после этого, что также вызовет git для воссоздания пакетов/индексов.

Ответ 12

Я решаю эту проблему, исправляя разрешение папки:

Источник

Bitbucket Support

Knowledge base

Products

Jira Software

Project and issue tracking

Jira Service Management

Service management and customer support

Jira Work Management

Manage any business project

Confluence

Bitbucket

Git code management

Resources

Documentation

Usage and admin help

Community

Answers, support, and inspiration

Suggestions and bugs

Feature suggestions and bug reports

Marketplace

Billing and licensing

Frequently asked questions

Viewport

Confluence

Git operations fail due to «git-pack-objects died with error»

Related content

Still need help?

The Atlassian Community is here for you.

Platform notice: Server and Data Center only. This article only applies to Atlassian products on the server and data center platforms .

Problem

Git commands don’t complete successfully.

The following appears in the command console output:

The following appears in the atlassian-bitbucket.log

Cause

There may be several causes for this problem:

Cause #1 — Corrupted Git repository

The database has become corrupted (e.g. as a consequence of a filesystem corruption).

Note: cloning the repository directly on the filesystem (without using Bitbucket Server) may still succeed since a Git clone does not run any additional checks and assumes that the repository is in a consistent state.

Workaround

Try to run the following commands to see if they resolve the problem:

• Stop Bitbucket Server
• Copy the $BITBUCKET_HOME/shared/data/repositories/ folder. This is to make sure that a backup of the entire repository is available.

Run the following commands from the $BITBUCKET_HOME/shared/data/repositories/ path:

If the steps above don’t resolve the problem, the repository may be not recoverable. In this case, the situation can be resolved by restoring a backup generated prior to the corruption.

Источник

Git pull не работает с ошибкой заголовка плохого пакета

git pull не работает со следующей ошибкой

Есть идеи, как успешно тянуть?

задан 09 сен ’11, 10:09

4 ответы

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

. настоятельно предполагает, что у вас закончилась память на сервере, что может произойти, если у вас есть:

1. Репозиторий с большим количеством больших файлов, из-за чего повторная упаковка может занять много памяти.
2. Ограниченная виртуальная память — либо в целом, либо только для этой учетной записи из-за ulimit установка

Предложение здесь состоит в том, чтобы ограничить объем памяти, который может занять упаковка, войдя в удаленную систему (как пользователь, от имени которого работает git) и выполнив:

Спасибо! Я получал ту же ошибку, что и OP. Я попытался реализовать элементы конфигурации pack.windowMemory и pack.SizeLimit, но все равно получал ошибку. Когда я добавил pack.threads «1», все разрешилось! — Brian C

Я с большим энтузиазмом начал, когда попытался перейти с svn на git. Но, переходя от одной неясной проблемы к проблеме, решение которой еще более неясно, я не уверен, насколько разумным было решение для перехода. — Рене Ниффенеггер

У меня возникла проблема с тем, что я меняю свойство pack.SizeLimit вместо pack.packSizeLimit. Это решило мою проблему. Большое тебе спасибо. — Звездочет

git config —global pack.windowMemory «100m» исправил мою проблему — Шадрак Кибет

Дополняя @Марк Лонгэйрответ:

Чтобы исправить эту проблему, мне пришлось выполнить следующие команды:

Вы можете увидеть больше об этих командах в документации git. git config .

Предупреждение: если вы видите эту ошибку с Git 2.19.1, это ожидаемо и задокументировано в git-for-windows/git выпуск 1839″ git gc сбой при 33% подсчета объектов »(который сообщает APPCRASH как для git gc , Но Также для git pull ) из-за мьютекса, используемого в «git pack-objects», который не был правильно инициализирован и вызвал » git repack «сбросить ядро ​​на винду.

Как упоминалось в выпуске:

Это влияет не только на gc . Я выбрал вариант с pull слишком:

pack-objects (mingw): инициализировать packing_data мьютекс в правильном месте

In 9ac3f0e ( pack-objects : исправить проблемы с производительностью при упаковке больших дельт, 2018-07-22, Git v2.19.0-rc1), был введен мьютекс, который используется для защиты вызова для установки размера дельты. Этот коммит даже добавил код для его инициализации, но в неправильном месте: в init_threaded_search() , а звонок oe_set_delta_size() (и, следовательно, packing_data_lock() ) может произойти в цепочке вызовов check_object() get_object_details() prepare_pack() cmd_pack_objects() , что задолго до prepare_pack() вызовы функций ll_find_deltas() (который инициализирует поточный поиск).

Еще один признак того, что мьютекс был инициализирован в неправильном месте, заключается в том, что функция для его инициализации находится во встроенном /, в то время как код, использующий мьютекс, определен в libgit.a заголовочный файл.

Источник

Git Не удалось выполнить клонирование с «index-pack»?

Итак, я создал удаленное репо, которое не было голым (потому что мне нужно, чтобы redmine мог его прочитать), и он должен быть разделен с группой (так что git init —shared = group). Я смог нажать на дистанционное репо, и теперь я пытаюсь клонировать его.

Если я клонирую его по сети, я получаю следующее:

Я могу клонировать его локально без проблем, и я запускал «git fsck», который сообщает только о некоторых висячих деревьях/блоках, которые, как я понимаю, не являются проблемой. Что может быть причиной этого? Я все еще могу извлечь из него, просто не клонировать. Я должен отметить, что удаленная версия git равна 1.5.6.5, а локальная — 1.6.0.4

Я попытался клонировать мою локальную копию репо, удалив папку .git и нажав на новое репо, затем клонируя новое репо, и я получаю ту же ошибку, что заставляет меня думать, что это файл в repo, что приводит к сбою git -upload-pack.

Изменить: У меня есть несколько двоичных файлов окон в репо, потому что я только что построил модули python, а затем закрепил их там, чтобы всем остальным не приходилось их создавать. Если я удалю двоичные файлы Windows и нажимаю на новое репо, я могу снова клонировать, возможно, это дает ключ. Попытка сузить точно, какой файл вызывает проблему сейчас.

ОТВЕТЫ

Ответ 1

Как я решил эту проблему: My git daemon работает в Windows, а клиенты находятся на других компьютерах.

Я нашел обходное решение (но оно будет работать только в окнах).

Запустите демон git с подробным из cmd.exe:

Не тестируется, если он работает непосредственно в git bash. Может быть, будет.

Затем (перед запуском любого клона, pull, fetch. ) выберите текст в окне (обратите внимание: «Режим быстрого редактирования» должен быть включен (можно найти в: cmd.exe → Свойства (щелкните верхний левый угол вашего окна cmd) → Параметры редактирования)), в котором запускается демон git. Это предотвратит его печать любых последующих сообщений в этом окне.

Когда выходной поток демона git заблокирован таким образом, ошибка не выполняется

Ответ 2

У меня та же проблема, что и вы; сообщение об ошибке при клонировании i:

В моем случае причина в том, что размер моего репозитория (200M) больше, чем моя серверная память git (128M). Когда я клонирую с сервера git , я использую команду top на моем сервере, которая показывает, что использование памяти скоро превысит 128M.

Когда я использую другой сервер с памятью 4G, git clone все в порядке. Вы также можете попробовать добавить дополнительное пространство подкачки к вашему серверу.

Ответ 3

Спрашивает ли «git gc»?

Ответ 4

У меня была та же проблема. Мое предположение также заключалось в том, что это связано с тем, что я использую режим text/CRLF для созданных файлов. И действительно, после переключения CygWin в UNIX/двоичный режим новой строки все работает нормально.

Кстати, самый простой способ переключить режим файла — редактировать /etc/fstab для переключения с

none/cygdrive cygdrive text, posix = 0, user 0 0

none/cygdrive cygdrive binary, posix = 0, пользователь 0 0

Ответ 5

У меня также были проблемы с cygwin git, ошибка: fatal: index-pack failed ,

Мне удалось решить эту проблему, создав mount для моих проектов и установив его в двоичный режим. поскольку мой /c установлен в текстовый режим.

Добавьте cygwin в /etc/fstab :

запустите mount -a , чтобы смонтировать все диски.

Вам нужно быть в /projects для работы с cygwin git , /c/work/Projects не удастся.

Не уверен, что это сработает для вас.

Ответ 6

Используйте переменную среды GIT_TRACE , чтобы получить вывод отладки. Установите для параметра «1» значение «stderr» или абсолютный путь к трассировке в файл.

Ответ 7

Я обновил свой клиентский компьютер git до той же версии, что и сервер, и это исправлено для меня.

Ответ 8

У меня та же проблема, и я бы изменил свои конфигурации git, и это нормально работает:

git config —global pack.packSizeLimit 50m
git config —global pack.windowMemory 50m
git config —global core.compression 9

Ответ 9

Проблема git-daemon, кажется, была решена в v2.17.0 (проверено с неработающим v2.16.2.1). Т.е. обходной путь выбора текста в консоли для «блокировки выходного буфера» больше не требуется.

• Ассорти исправления для «git daemon». (объединить ed15e58efe jk/daemon-fixes позже в maint).

Ответ 10

У меня была эта проблема или близкая к ней, но я не видел решения моего дела ни в одной из этих тем.

В моем случае проблема была в брандмауэре. Клонирование небольших репозиториев работало в любом случае, но большие не удавались. Так что, если больше ничего не помогает, настройки брандмауэра стоит проверить.

Ответ 11

Я столкнулся с этой проблемой, клонируя репозиторий github с github.com, запустив git 2.13 на SLES 12 SP3. Пробовал обновлять git до последней версии (v2.21 в то время), но это не помогло решить проблему. Пробовал настраивать параметры git config, предлагал и многие другие варианты, но не повезло.

В конце концов, я сделал это вручную.

• создал каталог вручную.. mkdir somedir
• Запустил git init чтобы настроить каталог для GIT.
• Вручную добавили репозиторий github в качестве источника git remote add origin http://github.com/git/git
• Побежал git fetch чтобы взять пачку. Эта задача .git/objects/pack/tmp_pack_XXXXXX ошибкой, но оставила пакет «извлечен, но плох» в .git/objects/pack/tmp_pack_XXXXXX
• подержанный cat.git/objects/pack/tmp_pack_XXXXXX | git unpack-objects -r cat.git/objects/pack/tmp_pack_XXXXXX | git unpack-objects -r чтобы извлечь все допустимые объекты.
• Запустил git fetch снова, чтобы пропустить что-то (например, ветки и теги) из предыдущих попыток. Никакая упаковка/объекты не нужны, потому что все они были распакованы.
• Наконец, git checkout master , чтобы HEAD указывал на что-то реальное.

Я не уверен, что это необходимо для меня, но я бы порекомендовал git fsck и git gc после этого, что также вызовет git для воссоздания пакетов/индексов.

Ответ 12

Я решаю эту проблему, исправляя разрешение папки:

Источник

Git pull не работает с ошибкой заголовка плохого пакета

Git pull не работает со следующей ошибкой

Есть идеи, как успешно тянуть?

4 ответа

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

. настоятельно предполагает, что у вас закончилась память на сервере, что может произойти, если у вас есть:

1. Репозиторий с большим количеством больших файлов, из-за чего повторная упаковка может занять много памяти.
2. Ограниченная виртуальная память — либо в целом, либо только для этой учетной записи из-за настройки ulimit

Предлагается здесь ограничить объем памяти, который может занять упаковка, войдя в удаленную систему (как пользователь, от имени которого работает git) и выполнив:

Дополняя ответ @Mark Longair :

Чтобы исправить эту проблему, мне пришлось выполнить следующие команды:

Подробнее об этих командах можно узнать в документации git конфигурация git .

Предупреждение: если вы видите эту ошибку в Git 2.19.1, это ожидаемо и описано в git-for-windows/git issue 1839:» git gc вылетает на 33% подсчитываемых объектов «(который сообщает APPCRASH как для git gc , так и также ) for git pull ) из-за мьютекса, используемого в «git pack-objects», который не был правильно инициализирован и заставил » git repack » сбрасывать ядро ​​в Windows.

Как упоминалось в выпуске:

Это влияет не только на gc . Я тоже выбрал его вариант с pull :

pack-objects (mingw): инициализировать мьютекс packing_data в правильном месте

В 9ac3f0e ( pack-objects : исправление проблем с производительностью при упаковке больших дельт, 2018 г.) -07-22, Git v2.19.0-rc1), был введен мьютекс, который используется для защиты вызова, чтобы установить размер дельты. Этот коммит даже добавил код для его инициализации, но в неправильном месте: в init_threaded_search() , в то время как вызов oe_set_delta_size() (и, следовательно, packing_data_lock() ) может произойти в цепочке вызовов check_object() get_object_details() prepare_pack() cmd_pack_objects() , что задолго до того, как функция prepare_pack() вызовет ll_find_deltas() (которая инициализирует многопоточный поиск).

Еще одним признаком того, что мьютекс был инициализирован в неправильном месте, является то, что функция для его инициализации находится во встроенном /, в то время как код, использующий мьютекс, определен в заголовочном файле libgit.a .

Источник

error: git-upload-pack died of signal 13

Troubleshooting Git

On this page

Related content

Still need help?

The Atlassian Community is here for you.

Platform notice: Server and Data Center only. This article only applies to Atlassian products on the server and data center platforms .

Problem

A clone operation of a Stash repository fails and the following message appears in the atlassian-stash.log:

Prior to version 3.7 this clone failure presented as an exception instead of being logged as an ERROR .

Cause

The error above does not represent an issue with Stash. It means that a Git client has closed its connection prematurely.

Resolution

You need to determine why the client connection closed before receiving all of the requested data. This is entirely a client-side issue.

We’ve updated the classification of the message (versions 3.10+) and it will now be displayed as INFO: The remote client has aborted the connection

Previous versions of Stash (up to 3.9) can be configured to display the updated message by installing the stash-stream-guard-plugin-1.0.0.jar add-on. Follow the instructions to installing by file upload.

Subgit

In the past this error has been caused by the Subgit plugin. The problem is trying to sync «global» patterns in .gitignore with a repo with many directories. This requires one permit per directory in subversion, which takes a lot of resources.

The fix in this case is to configure Subgit to turn off «ignore syncing» or use explicit file names in .gitignore

If you are using an Elastic Load Balancer we have noticed that the default ELB config has a low Idle timeout that should be increased. Git traffic often comes in bursts and can have long periods of silence that can trigger these timeouts. Search for «Idle Timeout» here for more information on how to configure this.

Источник

Большое спасибо! Проблема git clone решена.
Помог последний вариант.

Предупреждение: если вы видите эту ошибку с Git 2.19.1, это ожидаемо и задокументировано в git-for-windows/git выпуск 1839″git gc сбой при 33% подсчета объектов »(который сообщает APPCRASH как для git gc, Но Также для git pull) из-за мьютекса, используемого в «git pack-objects», который не был правильно инициализирован и вызвал «git repack«сбросить ядро ​​на винду.

Как упоминалось в выпуске:

Это влияет не только на gc. Я выбрал вариант с pull слишком:

$ git pull
remote: Enumerating objects: 3548, done.
error: git upload-pack: git-pack-objects died with error.
fatremote: aborting due to possible repository corruption on the remote side.
al: git uploadf-pack: aborting due to possible repository corruption on the remote side.
atal: protocol error: bad pack header

Это исправлено в Git 2.20 (4 квартал 2018 г.).
Видеть совершить 34204c8, совершить 9308f45, совершить ce498e0 (16 октября 2018 г.) Автор: Йоханнес Шинделин (dscho).
^{(Объединено Junio ​​C Hamano — gitster — in совершить 620b00e, 30 окт 2018)}

pack-objects (mingw): инициализировать packing_data мьютекс в правильном месте

In 9ac3f0e (pack-objects: исправить проблемы с производительностью при упаковке больших дельт, 2018-07-22, Git v2.19.0-rc1), был введен мьютекс, который используется для защиты вызова для установки размера дельты. Этот коммит даже добавил код для его инициализации, но в неправильном месте: в init_threaded_search(), а звонок oe_set_delta_size() (и, следовательно, packing_data_lock()) может произойти в цепочке вызовов check_object() <- get_object_details() <- prepare_pack() <- cmd_pack_objects(), что задолго до prepare_pack() вызовы функций ll_find_deltas() (который инициализирует поточный поиск).

Еще один признак того, что мьютекс был инициализирован в неправильном месте, заключается в том, что функция для его инициализации находится во встроенном /, в то время как код, использующий мьютекс, определен в libgit.a заголовочный файл.