Cách sử dụng git repack -a -d --depth = 250 --window = 250

Question

Tôi đã xem git gc --aggressive --prune và git repack -a -d --depth=250 --window=250 được đề xuất để giảm kích thước thư mục .git cục bộ của bạn khi không cần lịch sử địa phương dài. Từ đọc của tôi có vẻ như git-repack được ưa thích, bất kỳ ai có thể nhận xét về điều này?

Điều tôi thực sự muốn biết là cách quyết định giá trị cho depth và window. Tôi sử dụng git để cam kết, đẩy, kéo và hợp nhất, tôi không có ý tưởng những gì một chuỗi đồng bằng hoặc cửa sổ đối tượng là.

Answer 1

"Cửa sổ đối tượng" - khi đóng gói git so sánh từng đối tượng (mỗi phiên bản của mọi tệp, mọi đối tượng cây thư mục, mọi thư cam kết, mọi thẻ ...) với một số đối tượng tương tự khác tạo ra đồng bằng nhỏ nhất - gần như nói, miếng vá nhỏ nhất có thể tạo ra vật thể này từ đối tượng gốc đó.

"chuỗi Delta" - Khi nào, để tạo lại đối tượng A, trước tiên bạn phải kiểm tra đối tượng B và áp dụng đồng bằng cho nó, nhưng để tạo B bạn cần đối tượng C, yêu cầu D. ...

Tối đa một điểm, tăng cả depth và window có thể cung cấp cho bạn gói nhỏ hơn. Tuy nhiên, có sự cân bằng. Đối với window, cài đặt cao hơn có nghĩa là git repack sẽ so sánh từng đối tượng có nhiều đối tượng hơn trong khi đang chạy, dẫn đến thời gian chạy lâu hơn (có khả năng đáng kể) cho git repack. Tuy nhiên, khi gói được tạo, window không có tác dụng đối với các hoạt động tiếp theo (ngoài các trường hợp khác là repack s). depth, mặt khác, ít tác động đến thời gian chạy của git repack chính nó (mặc dù nó vẫn ảnh hưởng đến nó một chút), nhưng sâu hơn cây delta của bạn nhận được, còn phải xây dựng lại một đối tượng cũ từ chuỗi cơ sở các đối tượng cần thiết để tạo tệp. Điều đó có nghĩa là thời gian dài hơn đối với những thứ như checkout khi bạn tham khảo các cam kết cũ hơn, do đó, nó có thể có tác động đáng kể đến hiệu quả cảm nhận của git nếu bạn thực hiện nhiều thao tác trong lịch sử của mình. Và vì git không chỉ tạo ra vùng đồng bằng so với các đối tượng cũ hơn, nên đôi khi bạn có thể tìm thấy một đối tượng gần đây để trích xuất chậm bởi vì đó là một số cấp độ xuống cây - nó không phổ biến như với các đối tượng cũ hơn. .

Cá nhân tôi sử dụng window=1024 và depth=256 trên tất cả các khoản hoàn lại của mình ngoại trừ một vài bản sao của các dự án rất lớn (ví dụ: hạt nhân Linux).

Answer 2

Tôi đã chạy một số thử nghiệm với các giá trị khác nhau. Đây là quá lớn để có một bình luận về câu trả lời twalbergs.

Công ty của tôi có một cơ sở mã đã có trong svn, mercurial, và bây giờ git. Đó là 10 tuổi, với 21.000 cam kết.

Trước khi gói là 3,1 GB. Sau khi repack, nó thu nhỏ lại các giá trị sau:
(chạy repack trên một bản sao mới của thư mục 3.1GB mỗi lần).

git repack -a -d --depth=50 --window=10 -f 
141.584 MB 

git repack -a -d --depth=250 --window=1000 -f 
110.484 MB 

git repack -a -d --depth=500 --window=1000 -f 
110.204 MB 

Chúng mất khoảng 5, 15 và 30 phút tương ứng trên mac lõi tứ của tôi.

---

Cập nhật:

Tôi đã repack thứ hai (250,1000) và reran repack với 500, và 1000 để xem nếu có bất kỳ sự khác biệt giữa một repo 3.1gb tươi và đã repacked 110mb repo.

git repack -a -d --depth=250 --window=1000 -f 
110.484 MB 
git repack -a -d --depth=500 --window=1000 -f 
110.212 MB 

Phán quyết: repack 500, 1000 dẫn đến tệp 110,2 MB bất kể tệp đã được đóng gói hay chưa.

Update2:

Tôi đã thêm tò mò nếu chạy một repack với giá trị thấp hơn trên một repo đã repacked sẽ gây ra kích thước tăng lên.

git repack -a -d --depth=500 --window=1000 -f 
110.204 MB 
git repack -a -d --depth=50 --window=10 -f 
142.056 MB 

Dự đoán: các repack gây ra kích thước repo để bóng trở lại lên đến ~ 140 MB từ 110 MB