Git 커밋 하나는 얼마나 클까?
How big is a Git commit?
Git 커밋의 실제 크기는 파일의 압축률과 packfile 사용 여부에 따라 달라진다. 실험 결과, 빈 저장소 초기화에 약 64KB가 필요하고, 250개의 작은 파일을 커밋하면 47KB가 추가된다. 단일 파일 저장소에서는 커밋당 약 8KB가 소요되며, 583KB 바이너리 파일은 300KB로, 16.4MB 소스 파일은 1.6MB로 압축되어 저장된다. 작은 커밋에는 킬로바이트 단위의 오버헤드가 발생하지만, 큰 커밋은 원본 대비 10~50% 크기로 매우 효율적으로 저장된다.
그래서 16.4MB 소스 파일을 커밋하는 데 1.6MB가 걸렸다! 텍스트가 잘 압축될 거라고 예상했지만, 이건 정말 인상적이다.
HN 토론
21- cocoto
> du 옵션은 s는 요약, b는 바이트 표시입니다.
사소한 지적: 긴 옵션을 사용하면 코드 예제가 스스로 설명이 됩니다!
- nathanpankon
워크플로우에 맞춰 간소화한 git 대안을 만들어 보면서 놀았습니다. 완전히 포기한 건 아니지만, 제 핵심 아이디어는 ast 경로를 사용해 데이터를 더 압축할 수 있다는 것이었습니다.
말씀하신 대로 git은 정말 효율적이고, chromium이라는 작업(엉망)과 버전 간에 완전한 재빌드를 강제하지 않고 문제를 해결하기 위해 했던 깊은 해킹 때문에 비판적인 시각으로 접근했지만
압축 대안으로서 제 접근 방식은 가치가 없다는 결론에 도달했습니다. Git이 더 잘했어요!
어쨌든 시도한 것은 여기 있습니다: https://github.com/pankon/gat
- jamesblonde
Git은 로컬 파일 저장소에 대한 가정을 가지고 설계되어 분산 파일 시스템에 데이터를 저장할 때 어려움이 있습니다. 우리는 분산 파일 시스템인 HopsFS를 S3에 데이터를 저장하도록 구축했습니다. FUSE에서 고성능 git을 지원하기 위해 쓰기는 원격 NVMe 디스크에 도달하고 비동기적으로 S3에 동기화됩니다(NVMe에 복제하거나 실패 복구만 해도 됩니다). 이전에는 원격 NVMe 디스크를 write-through 캐시로 사용했지만, git에서는 작동하지 않았고 S3 지연 시간이 너무 높았습니다.
요구 사항: