Git 클론은 프록시를 통해 동작하지만 Git LFS는 실패한다
정상적으로 동작하는 프록시를 바꾸기 전에 Git LFS 메타데이터와 객체 다운로드를 Git 클론과 분리해 추적한다.
클론이 Git 객체 전송을 마쳤어도 LFS 콘텐츠는 여전히 없을 수 있다. Git은 포인터 파일을 저장하고, LFS 클라이언트는 대용량 객체를 별도로 요청한다.
Git LFS가 설치된 해당 체크아웃에서 엔드포인트와 마지막 실패를 확인한다:
git -C project lfs env
git -C project lfs logs last출력은 로컬에서 검토한다; 저장소 URL과 로그는 식별 정보나 인증 정보를 노출할 수 있다. 처음 실패한 단계를 파악한다:
- LFS API에 연결하는 단계.
- Batch API의 다운로드 액션을 얻는 단계.
- 해당 액션의 다운로드 URL에 도달하는 단계. 이 URL은 다른 객체 스토리지 호스트와 제공된 헤더를 사용할 수 있다.
- 객체 본문을 전송하는 단계.
실제 URL뿐 아니라 저장소의 LFS 엔드포인트 재정의도 확인한다. LFS는 자체 HTTP 구현, 구성, 상속된 프록시 환경을 가진다. Git LFS 3.7.0에서는 실제 요청 URL에 대해 해당 프록시 선택 순서를 따른다. 일반 Git HTTPS 호스트에 도달하는 것만으로는 이후의 모든 객체 경로를 시험하지 못한다. 객체 호스트 인증 실패는 프록시 407과도 별개다.
다운로드를 의도한 경우, 통제된 저장소에서 별도로 페치하면 다른 클론 없이 실패를 드러낼 수 있다:
git -C project lfs fetch이것은 객체를 전송하며 읽기 전용 설정 조회가 아니다. 이후 필요한 콘텐츠를 사용할 수 있는지 확인한다. 부분 체크아웃에 남은 작은 포인터는 대용량 파일이 아니며, 이전에 성공한 Git 명령은 LFS 전송이 완료되었음을 입증할 수 없다.