Почему бы git -upload-pack (во время git clone) зависать?

Я прочитал несколько других вопросов git зависает на клоне, но ни одна из них не соответствует моей среде и деталям. Я использую git, созданный под cygwin (msys git не является вариантом), чтобы клонировать репо с хоста Linux через SSH.

git clone [email protected]:repo

Я тестировал тот же хост на других платформах, и он отлично работает, но на этой машине Windows клон вешает бесконечно. Я установил GIT_TRACE=1, и похоже, что проблема связана с этой командой:

'ssh' '[email protected]' 'git-upload-pack '\''repo'\'''

Мои ключи SSH настроены правильно: ssh [email protected] работает нормально. Когда я запускаю команду, я получаю кучу вывода, который заканчивается следующим образом:

...
003dbbd3db63763922ad75bbeefa3811dce001576851 refs/tags/start
0000

Затем он висит на 20 + минут, что является самым длинным, которое я ждал, прежде чем убить его.

Сервер имеет git 1.7.11.7 с OpenSSH 5.9p1, а клиент имеет git 1.7.9 с OpenSSH 6.1p1.

Предполагается, что это конец вывода git -upload-pack? Является ли это ошибкой в git или моей конфигурации?

Ответ 1

Предстоящий git1.8.5 (Q4 2013) будет документировать больше протокола smart http.
См. commit 4c6fffe2ae3642fa4576c704e2eb443de1d0f8a1 Шон О. Пирс.

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

Это может помочь определить, где служба "зависает".

Файл Documentation/technical/http-protocol.txt настаивает на:

Smart Service git -upload-pack"
- Клиенты ДОЛЖНЫ сначала выполнить открытие ref с помощью < $GIT_URL/info/refs?service=git-upload-pack.
```
C: POST $GIT_URL/git-upload-pack HTTP/1.0
S: 200 OK
S: Content-Type: application/x-git-upload-pack-result
S: Cache-Control: no-cache
S:
S: ....ACK %s, continue
S: ....NAK
```
- Клиенты НЕ ДОЛЖНЫ повторно использовать или повторно проверять кешированный ответ.
- Серверы ДОЛЖНЫ включать в себя достаточные заголовки Cache-Control для предотвращения кэширования ответа.
- Серверы ДОЛЖНЫ поддерживать все возможности, определенные здесь.
- Клиенты ДОЛЖНЫ отправить хотя бы одну команду "хочу" в тело запроса.
- Клиенты НЕ ДОЛЖНЫ указывать идентификатор в команде "хочу", которая не отображалась в ответе, полученном при обнаружении ref, если только сервер не рекламирует возможность "allow-tip-sha1-in-want".

алгоритм "отрицания"

(c) Send one $GIT_URL/git-upload-pack request:
C: 0032want <WANT #1>...............................

Ответ 2

Устаревший PuTTy также может вызвать это. Ваша система может использовать plink.exe как GIT_SSH.

Вы можете установить последнюю конструкцию разработки из http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html, чтобы убедиться, что это не проблема.

Ответ 3

Мы столкнулись с аналогичной проблемой, и мы объяснили это следующим образом: у нашего git repo есть много двоичных файлов, проверенных (несколько версий за последние 1,5 года этого проекта). Итак, мы предположили, что это было причиной.

Чтобы поддержать эту теорию, у нас есть другие базовые базы кода, которые являются более новыми (и, следовательно, не так много бинарных файлов и их версий), которые не проявляют этого поведения.

Наша настройка: git настройка на linux, межсетевое VPN-соединение между Лондоном и Индией по линии T1.

Ответ 4

У меня была такая же проблема после того, как я добавил такой jazz, как это, в мою конфигурацию ssh, чтобы установить заголовки окон в tmux:

Host *
PermitLocalCommand yes
LocalCommand if [[ $TERM == screen* ]]; then printf "\033k%h\033\\"; fi

избавиться от этого исправленного my git.

Ответ 5

Это сработало для меня, если оно помогает кому-то другому.

Проверьте свой git удаленный URL. Он может зависать с git-upload-pack на трассе, если вы используете неправильный тип URL. измените URL-адрес от [email protected]: до https://github.com/ на пульте дистанционного управления.