Git 팩파일 뷰어 (.pack / .idx)

복원된 객체가 아니라 델타 자체의 크기이기 때문입니다. 델타 객체는 다른 객체를 이 객체로 바꾸는 지시, 즉 베이스의 어느 구간을 복사하고 어떤 바이트를 새로 넣으라는 명령만 담고 있으며 헤더의 크기는 그 명령 스트림의 길이입니다. git verify-pack -v도 같은 이유로 같은 값을 출력합니다. 복원 후 크기는 압축된 델타 데이터 안에 적혀 있어서 압축을 풀어야만 알 수 있고, 이 페이지는 일부러 풀지 않습니다.

둘 다 델타를 저장하지만 베이스를 가리키는 방법이 다릅니다. ofs-delta는 자기 오프셋에서 뒤로 몇 바이트인지를 적어 짧고 자족적이며, ref-delta는 베이스의 전체 객체 id를 적어 20바이트나 32바이트를 쓰고 조회가 필요합니다. git은 1.5부터 기본으로 ofs-delta를 쓰고, repack.useDeltaBaseOffset을 false로 두는 등 아주 오래된 클라이언트를 배려할 때나 베이스가 이 팩에 아예 없을 때만 ref-delta를 씁니다. 후자는 fetch 중에 오가는 thin 팩의 모습입니다.

득실의 문제입니다. 체인 길이는 객체 하나를 되살리려고 델타를 몇 번 이어서 적용해야 하는지를 뜻하므로 깊이가 50이면 그 객체 하나를 읽는 데 51개 객체를 건드립니다. 체인이 깊으면 더 작게 저장되고 더 느리게 읽히며, git은 repack의 --depth로 이를 제한합니다. 기본값은 50입니다. 대부분의 객체가 깊이 0이라면 델타 압축이 별 도움이 되지 않은 것이고, 보통 이미지나 압축 파일처럼 이미 압축된 내용이 그 원인입니다.

이름으로는 알 수 없습니다. 팩은 경로가 아니라 객체를 담습니다. blob에는 이름이 없고 파일 이름은 tree 객체 안에 있으며 그것도 압축되어 있습니다. 이 페이지가 주는 것은 가장 큰 객체의 id이고, 거기서부터는 저장소에서 git rev-list --objects --all로 경로를 찾거나 git cat-file -p로 내용을 볼 수 있습니다. id에서 크기로, 다시 경로로 가는 이 순서가 "왜 클론이 2GB인가"를 밝히는 일반적인 방법입니다.

압축을 풀지 않고는 안 됩니다. 객체는 서로 붙어 있고 압축 데이터의 길이를 적은 칸이 없어서, 하나가 어디서 끝나는지 알려면 zlib 스트림이 끝날 때까지 풀어 보는 수밖에 없습니다. .idx에는 모든 오프셋이 이미 들어 있으므로 팩에서의 크기는 다음 오프셋까지의 거리가 되고 어디서도 압축을 풀 필요가 없습니다. 인덱스가 아예 없는 팩이라면 git도 git index-pack으로 다시 만드는데, 그 명령은 모든 객체의 압축을 풉니다.

인덱스의 마지막 두 해시는 자신이 설명하는 팩의 체크섬과 인덱스 자신의 체크섬입니다. 값이 다르면 두 파일이 함께 만들어지지 않았다는 뜻입니다. 보통 서로 다른 곳에서 복사되었거나 한쪽만 다시 만들어진 경우이고, 그러면 인덱스의 오프셋이 엉뚱한 바이트를 가리켜 이후의 종류와 크기가 모두 무의미해집니다. 해결책은 그 짝을 믿지 않는 것입니다. 팩을 다시 받거나 git index-pack으로 인덱스를 다시 만드세요.