"델타 해결 중"이라고 말하면 실제로 git은 무엇을하고 있습니까?

저장소의 첫 번째 복제 동안 git은 먼저 객체를 수신하고 (충분히 명백한) "델타 해결"과 거의 같은 시간을 소비합니다. 이 복제 단계에서 실제로 어떤 일이 발생합니까?

Git은 델타 인코딩 을 사용 하여 일부 객체를 팩 파일에 저장합니다. 그러나, 당신은 매일 변화를 재생하고 싶지 않아 지금까지 힘내는 물론 저장된 파일 내용의 한 단면을 가지고 있으므로, 현재 버전을 얻기 위해 주어진 파일에. "델타 해결"은 모든 것을 일관성있게 유지하는 단계입니다.

다음 은 온라인으로 이용할 수있는 Pro Git 서적의 "Git Internals"섹션에있는 장입니다.

단계 git clone는 다음 과 같습니다.

1. repo 데이터베이스에있는 모든 객체의 "팩"파일을받습니다.
2. 수신 된 팩에 대한 색인 파일 작성
3. 헤드 리비전을 확인하십시오 (비 베어 리포지토리의 경우).

"델타 해결"은 팩 파일을 색인화하는 두 번째 단계 ( "git index-pack")에 표시되는 메시지입니다.

팩 파일 에는 실제 객체 ID 가 없고 객체 내용 만 있습니다. 따라서 객체 ID가 무엇인지 확인하려면 git은 팩의 각 객체에 대해 압축 해제 + SHA1을 수행하여 객체 ID를 생성 한 다음 인덱스 파일에 기록해야합니다.

팩 파일의 객체는 델타, 즉 다른 객체를 변경하기위한 일련의 변경으로 저장 될 수 있습니다. 이 경우 git은 기본 객체를 검색하고 명령을 적용하고 결과를 SHA1해야합니다. 기본 개체 자체는 일련의 델타 명령을 적용하여 파생되어야합니다. (복제본의 경우에도 기본 개체가 이미 발생 했으므로 메모리에 캐시 된 제조 개체 수에 제한이 있습니다).

요약하면, "델타 해결"단계에서는 전체 리포지토리 데이터베이스의 압축을 풀고 체크섬하는 작업이 필요합니다. 아마도 SHA1의 압축을 풀고 계산하는 것은 실제로 델타 명령을 적용하는 것보다 더 많은 시간이 걸립니다.

후속 페치의 경우, 수신 된 팩 파일은 수신 git이 이미 가질 것으로 예상되는 다른 오브젝트에 대한 참조 (델타 오브젝트베이스로서)를 포함 할 수 있습니다. 이 경우, 수신 git은 실제로 수신 된 팩 파일을 다시 작성하여 참조 된 오브젝트를 포함하므로 저장된 팩 파일이 충분합니다. "델타 해결 중"메시지가 시작된 곳일 수 있습니다.

Amber는 Mercurial 또는 이와 유사한 용도로 사용되는 객체 모델을 설명하는 것 같습니다. Git은 매번 후속 버전의 객체 사이에 델타를 저장하지 않고 객체의 전체 스냅 샷을 저장합니다. 그런 다음 델타 압축을 사용하여 이러한 스냅 샷을 압축하고 히스토리의 위치에 상관없이 사용할 델타를 찾습니다.