Подтвердить что ты не робот

Git клон с прокси-сервером NTLM зависает после разрешения дельт

Я видел здесь много вопросов, охватывающих темы git и прокси, но ни одна из них не решает мою проблему. Я клонирую репозиторий git от Bitbucket. Все работает отлично от моей домашней сети, но висит на работе, где мы используем прокси с аутентификацией NTLM. Смотрите вывод команды git clone: ​​

$ git clone https://[email protected]/my_user/my_project.git --verbose
Cloning into 'my_project'...
Password for 'https://[email protected]':
POST git-upload-pack (174 bytes)
remote: Counting objects: 548, done.
remote: Compressing objects: 100% (367/367), done.
remote: Total 548 (delta 216), reused 0 (delta 0)
Receiving objects: 100% (548/548), 5.28 MiB | 533 KiB/s, done.
Resolving deltas: 100% (216/216), done.

git Команда clone всегда зависает на "Разрешение дельт".

Моя настройка:

  • 64-разрядная версия Windows 7 с msysgit 1.8.0

  • настроен прокси:

    $git config --global http.proxy http://MY_DOMAIN\\\my_user:[email protected]:8080

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

4b9b3361

ОТВЕТЫ

Ответ 1

Я попал в ту же проблему, с Git 1.7.11. Все мои попытки клонировать из GitHub приводят к зависанию процесса без файлов. Я попробовал трюк verify-pack и многие другие предложения в похожих вопросах, но ничего не получилось.

Я подумал, что, возможно, это было улучшено или исправлено в последней версии Git, поэтому я обновился до 1.8.3. Бинго, теперь он работает, я могу клонировать!

Ответ 2

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

У меня такая же проблема. Я не могу найти и исправить проблему, но я, наконец, смог проверить. Когда клон git висит на "Разрешение дельт", убейте процесс git. Итак, у вас есть папка my_project и файл .git\objects\pack\pack-<sha1>.pack. Теперь нам нужно найти номер ревизии. Введите следующую команду:

git verify-pack -v .git\objects\pack\pack-<sha1>.pack | grep "commit" | more

и вывод выглядит примерно так:

98c9f779992fc9a52372e0a1a76647e5d9ca5e01 commit 340 227 12
b6435d98f7b62ce69c59ce582beddf547f26d8a2 commit 305 208 239
a2a39a0c707b2919c87b194dca9a0dea307ce069 commit 239 159 447
...
4803e013b30dc9d31e4a8dba7e1a2d65e6f61422 commit 243 167 6768
-- More  --

98c9f779992fc9a52372e0a1a76647e5d9ca5e01 вверху - ревизия HEAD, поэтому вы можете проверить до этой точки:

git checkout -b master 98c9f779992fc9a52372e0a1a76647e5d9ca5e01

Готово.

Ответ 3

У меня такая же проблема, и хотя я не могу точно определить причину, у меня есть то, что я считаю, немного лучше обходным путем, чем использование проверочного пакета и проверка последнего фиксации, как объясняется cakyus.

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

  • Прервать процесс git, зависающий при разрешении дельта с помощью Ctrl+C
  • Получить информацию о филиале с помощью git fetch
  • Оформить главную ветку (или любую другую ветку) с помощью git checkout master

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

Ответ 4

Не ответ, просто способствующие симптомы, чтобы сузить причину этой проблемы. У меня такая же проблема. Он просто сидит там "разрешая дельту".

v1.7.10 Win2008 R2 Enterprise Прокси настроен для HTTP и HTTP.

Я получу коллегию для входа на сервер (.gitconfig является частью его перемещаемого профиля) и посмотрите, не является ли это конфигурацией или установкой.

Ответ 5

Решение, которое работает для меня из комментариев в этом блоге http://stas-blogspot.blogspot.ca/2012/12/git-hangs-after-resolving-deltas.html:

Так как файлы пакета были загружены правильно, все, что вам нужно сделать, это прервать процесс с помощью Ctrl + C, сделать git fetch для извлечения информации о ветке из удаленного репозитория и проверить снова мастер (или любую другую) ветку с мастером проверки git.

поэтому решение состоит в том, чтобы просто убить процесс подвески, а затем:

git fetch
git checkout

Ответ 6

Две вещи (апрель 2019 года, семь лет спустя):

  1. Не объявляйте URL-адрес прокси NTML напрямую. Задайте HTTPS_PROXY переменных среды HTTP_PROXY и HTTPS_PROXY значение "Прокси-сервер HTTP" (а не для NTLM), например, с помощью genotrance/px.
    Запустив px (который перенаправляет на ваш NTLM-прокси), вы можете обратиться к классическому HTTP-прокси (обычно http://localhost: 3128, вам не нужны ваши логин/пароль!), И это будет работать лучше.

  2. Если "Разрешение дельт" все еще занимает много времени, обязательно используйте Git 2.22 (Q2 2019)

По этому второму пункту: индикатор прогресса был добавлен к шагу " index-pack ", который часто заставляет пользователей ждать завершения во время " git clone ".

См. Коммит 79e3aa6 (31 марта 2019 г.) SZEDER Gábor (szeder).
(Объединено Junio C Hamano - gitster - в коммите da924b5, 25 апреля 2019 г.)

index-pack: показать прогресс при проверке объектов

Когда " git index-pack " запускается " git clone ", его check_objects() обычно не занимает достаточно много времени, чтобы вызывать беспокойство, но я просто сталкиваюсь с ситуацией, когда это заняло около минуты или около того: я случайно при клонировании linux.git оказывалось некоторое давление на память моего крошечного ноутбука, а затем между полосами выполнения " Resolving deltas " и " Checking connectivity " было довольно долгое молчание.

Показать индикатор выполнения во время цикла check_objects() чтобы дать пользователю знать, что что-то еще происходит.