Git clone работает через прокси, но Git LFS завершается с ошибкой

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

Клонирование может завершить передачу объектов Git, пока содержимое LFS всё ещё отсутствует. Git хранит файлы-указатели; клиент LFS выполняет отдельные запросы для больших объектов.

В затронутой рабочей копии с установленным Git LFS проверьте его endpoint и последнюю ошибку:

git -C project lfs env
git -C project lfs logs last

Изучите вывод локально; URL-адреса репозитория и журналы могут раскрывать идентифицирующую информацию или данные аутентификации. Определите первый неудавшийся этап:

  1. Обращение к API LFS.
  2. Получение действия загрузки из Batch API.
  3. Обращение к URL загрузки этого действия, который может использовать другой хост объектного хранилища и переданные заголовки.
  4. Передача тела объекта.

Проверьте переопределения endpoint LFS в репозитории, а также фактический URL. LFS имеет собственную реализацию HTTP, конфигурацию и унаследованное окружение прокси. Для Git LFS 3.7.0 следуйте порядку выбора прокси для фактического URL запроса. Обращение к обычному HTTPS-хосту Git не задействует все последующие маршруты к объектам. Ошибка аутентификации на хосте объектов также отличается от прокси 407.

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

git -C project lfs fetch

Он передаёт объекты; это не запрос настроек только для чтения. После этого убедитесь, что нужное содержимое доступно. Небольшой указатель, оставшийся в частичной рабочей копии, — это не большой файл, и успешная ранее команда Git не доказывает, что передача LFS завершилась.

Похожие статьи