Git клонирование: удаленный конец неожиданно повесил трубку, попытался изменить postBuffer, но все еще не удалось

Я пытаюсь клонировать репозиторий. В первый раз, когда я добрался до 82%, тогда он не сдвинулся с места на полчаса, поэтому я отменил клон и начал работу. После этого каждый раз, когда я пытаюсь клонировать его, я получаю от 6 до 10%, а затем он терпит неудачу с ошибкой "Удаленный конец неожиданно неожиданно повредил EOF". Я искал ошибку и пробовал каждое решение, которое мог найти, причем самым популярным решением было увеличение postBuffer до максимального размера. Однако он все равно терпит неудачу каждый раз.

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

ОТВЕТЫ

Ответ 1

Если это транзакция http, вам нужно связаться с поддержкой BitBucket для их диагностики, что пошло не так на стороне сервера.
Как упоминалось, например, " howto/use-git-daemon":

fatal: The remote end hung up unexpectedly

Это означает, что что-то пошло не так. Чтобы узнать, что пошло не так, вам нужно спросить сервер.

Обратите внимание, что когда BitBucket будет использовать Git 2.5+ (Q2 2015), клиент может получить более явное сообщение об ошибке:

 request was larger than our maximum size xxx
 try setting GIT_HTTP_MAX_REQUEST_BUFFER"

(т.е. установка GIT_HTTP_MAX_REQUEST_BUFFER на сервере хостинга репозитория Git)

См. commit 6bc0cb5 Джефф Кинг (peff), 20 мая 2015 года.
(слияние Юнио С Хамано - gitster - в совершить 777e75b, 01 июня 2015 г.)
Test-adapt-from: Деннис Каарсмейкер (seveas)

Новая переменная среды GIT_HTTP_MAX_REQUEST_BUFFER:

Переменная среды GIT_HTTP_MAX_REQUEST_BUFFER (или http.maxRequestBuffer config), можно изменить самый большой запрос согласования ref, который Git будет обрабатывать во время выборки; Любые выборка, требующая большего буфера, не будет выполнена.

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

Значение может быть указано с помощью устройства (например, 100M для 100 мегабайт). Значение по умолчанию - 10 мегабайт.

Объяснение очень интересно:

http-backend: запросы согласования spool ref в буфер

Когда http-backend порождает " upload-pack "сделать ref переговоры, он передает тело запроса http на upload-pack, который затем передает HTTP-ответ обратно клиент, как он читает.
Теоретически Git может идти в полнодуплексном режиме; клиент может использовать наш ответ, пока он по-прежнему отправляет запрос.
На практике, однако, HTTP является полудуплексным протоколом.
Даже если наш клиент готов одновременно читать и писать, у нас может быть другая инфраструктура HTTP, в том числе веб-сервер, который порождает наш CGI или любые промежуточные прокси.

По крайней мере в одном документированном случае это приводит к взаимоблокировке при попытке получения из-за http.
Что происходит в основном:

  • Apache проксирует запрос к CGI, http-backend.
  • http-backend gzip - раздувает данные и отправляет результат на загрузку.
  • upload-pack действует на данные и генерирует вывод по каналу обратно в Apache. Apache не читает, потому что он занят письмом (шаг 1).

Это отлично работает отлично, потому что upload-packвывод заканчивается буфером системных каналов, и Apache читает это как только он заканчивает писать. Но если оба запроса и ответ превышает размер буфера системы, тогда мы тупик (блоки Apache записываются в http-backend, http-backend блокирует запись в upload-pack и upload-pack блокирует запись в Apache).

Нам нужно выйти из тупика, намотав либо вход или выход. В этом случае он идеально подходит для катушки ввода, потому что Apache не запускает чтение либо stdout, либо stderr, пока мы не уничтожим все входные данные. Итак, пока мы сделайте это, мы даже не можем получить сообщение об ошибке клиент.

Решение довольно прямолинейно: мы читаем запрос тело в буфер памяти в http-backend, освобождая Apache, а затем сами подайте данные на upload-pack.