गिट repack -a -d --depth = 250 - विन्डो = 250

Question

मैंने git gc --aggressive --prune और git repack -a -d --depth=250 --window=250 को अपने स्थानीय .git फ़ोल्डरों के आकार को कम करने के लिए अनुशंसित किया है जहां एक लंबे स्थानीय इतिहास की आवश्यकता नहीं है। मेरे पढ़ने से ऐसा लगता है कि git-repack पसंद किया गया है, क्या कोई इस पर टिप्पणी कर सकता है?

मैं वास्तव में जानना चाहता हूं कि depth और window के मानों पर निर्णय कैसे लें। मैं प्रतिबद्ध, पुश, पुल और मर्ज करने के लिए गिट का उपयोग करता हूं, मुझे नहीं पता कि डेल्टा चेन या ऑब्जेक्ट विंडो क्या है।

Answer 1

"ऑब्जेक्ट विंडो" - git को रीकैक करते समय प्रत्येक ऑब्जेक्ट (प्रत्येक फ़ाइल का प्रत्येक संस्करण, प्रत्येक निर्देशिका वृक्ष वस्तु, प्रत्येक प्रतिबद्ध संदेश, प्रत्येक टैग ...) की तुलना किसी अन्य समान-आइस ऑब्जेक्ट्स की एक निश्चित संख्या के विरुद्ध करता है जो सबसे छोटा डेल्टा बनाता है - मोटे तौर पर बोलते हुए, सबसे छोटा पैच जो इस ऑब्जेक्ट को उस मूल वस्तु से बना सकता है।

"डेल्टा चेन" - जब ऑब्जेक्ट ए को फिर से बनाने के लिए, आपको पहले ऑब्जेक्ट बी को जांचना होगा और इसे डेल्टा लागू करना होगा, लेकिन बी बनाने के लिए आपको ऑब्जेक्ट सी की आवश्यकता होती है, जिसके लिए डी की आवश्यकता होती है। ...

एक बिंदु तक, depth और window दोनों को बढ़ाकर आप छोटे पैक दे सकते हैं। हालांकि, ट्रेडऑफ हैं। window के लिए, एक उच्च सेटिंग का अर्थ है कि git repack प्रत्येक ऑब्जेक्ट की तुलना में अधिक ऑब्जेक्ट्स के साथ तुलना करेगा, जिसके परिणामस्वरूप (संभावित रूप से महत्वपूर्ण) git repack के लिए लंबे समय तक चलने का समय होगा। हालांकि, पैक उत्पन्न होने के बाद, window का आगे के संचालन पर कोई प्रभाव नहीं पड़ता है (अन्य repack एस के बाहर, वैसे भी)। depth, दूसरी ओर, git repack के रन टाइम पर कम प्रभाव पड़ता है (हालांकि यह अभी भी इसे कुछ हद तक प्रभावित करता है), लेकिन आपके डेल्टा पेड़ जितना गहरा हो जाता है, उतना ही लंबे समय तक मूल वस्तु को फिर से बनाने के लिए ले जाता है फाइल बनाने के लिए आवश्यक वस्तुओं। इसका मतलब है कि checkout जैसी चीजों के लिए लंबा समय लगता है जब आप पुराने कामकाज का संदर्भ दे रहे हैं, तो यदि आप अपने इतिहास के माध्यम से बहुत खुदाई करते हैं तो git की कथित दक्षता पर इसका महत्वपूर्ण प्रभाव हो सकता है। और, चूंकि git पुराने ऑब्जेक्ट्स के खिलाफ केवल डेल्टा नहीं बनाता है, तो आप अवसर पर एक हालिया ऑब्जेक्ट पा सकते हैं जो निकालने में धीमा है क्योंकि यह पेड़ के नीचे कई स्तर हैं - यह पुरानी वस्तुओं के समान नहीं है, लेकिन ऐसा होता है ।

मैं व्यक्तिगत रूप से window=1024 और depth=256 का उपयोग अपने सभी रिपोज़ पर बहुत बड़ी परियोजनाओं (जैसे लिनक्स कर्नेल) के कुछ क्लोन को छोड़कर करता हूं।

Answer 2

मैंने विभिन्न मूल्यों के साथ कुछ परीक्षण चलाए। Twalbergs उत्तर पर एक टिप्पणी होने के लिए यह बहुत बड़ा है।

मेरी कंपनी का एक कोड बेस है जो svn, mercurial, और अब गिट में रहा है। यह 10 साल पुराना है, 21,000 काम करता है।

पैक से पहले यह 3.1 जीबी था। Repack के बाद, यह निम्नलिखित मानों के लिए shrunk:
(हर बार 3.1 जीबी फ़ोल्डर के ताजा क्लोन पर repack चला रहा है)।

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 

उन्होंने मेरे क्वाड कोर मैक पर क्रमश: 5, 15 और 30 मिनट का समय लिया।

---

अद्यतन:

मैं दूसरे repack (250,1000) ले लिया और 500 के साथ repack reran, और 1000 अगर वहाँ एक ताजा 3.1gb रेपो और एक पहले से ही के बीच कोई अंतर है देखने के लिए 110 एमबी रेपो repacked।

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

फैसले: repack 500, 1000 की परवाह किए बिना एक 110.2 एमबी फ़ाइल के परिणामस्वरूप यदि वह पहले से पैक किया गया था या नहीं।

Update2:

मैं अगर एक पहले से ही repacked रेपो पर कम मूल्यों के साथ एक repack चल आकार बढ़ाने के लिए कारण होगा आगे उत्सुक था।

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

फैसले: repack वजह से रेपो आकार 110 एमबी से वापस ~ 140 MB तक balloon को