पर गिट उथला क्लोन मैं लिनक्स कर्नेल रेपो को क्लोन करना चाहता हूं, लेकिन केवल संस्करण 3.0 से ही, क्योंकि कर्नेल रेपो इतना बड़ा है क्योंकि अगर मैं उथले क्लोन कर सकता हूं तो यह मेरे वर्जनिंग टूल्स तेज़ी से चलाता है। मेरे प्रश्न का मूल यह है: मैं गिट बता सकता हूं कि "डी" मान --depth पैरामीटर के लिए क्या है? मुझे उम्मीद थी इस काम करेगा:विशिष्ट टैग
Git क्लोन http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git --depth v3.0
धन्यवाद।
दुर्भाग्यवश git clone पैरामीटर केवल एक संख्या स्वीकार करता है, जिसमें क्लोनिंग रिपोजिटरी को छोटा किया जाना चाहिए, संशोधनों की संख्या।
एक संभावित समाधान पूरे भंडार को क्लोन करना है, और फिर v3.0 के बाद ही काम करने के लिए अपने इतिहास को छोटा कर दें। http://bogdan.org.ua/2011/03/28/how-to-truncate-git-history-sample-script-included.html
git checkout --orphan temp v3.0
git commit -m "Truncated history"
git rebase --onto temp v3.0 master
git branch -D temp
git gc
यह मेरे साथ प्रदान किए गए समाधान के साथ-साथ काम करना चाहिए, लेकिन मैं अन्य सभी स्थानीय संदर्भों को हटाने और मेरे समाधान में क्लीनअप चरणों को चलाने का भी सुझाव दूंगा। इसके बिना, रेपो में अभी भी पूर्ण इतिहास और अतिरिक्त वस्तुएं होंगी। इस रेपो के साथ जो आवश्यकतानुसार लगभग 2 मिलियन ऑब्जेक्ट्स लटक रहा है। – James
अच्छा नोट, जोड़ा गया – tomgi
इस रणनीति को विरोधाभासी विलयों के प्रबंधन की आवश्यकता है और विलय को संभालने के तरीके के आधार पर अंतिम मास्टर की सटीक प्रति नहीं बनाने का जोखिम चलाता है। चूंकि रेपो इतना बड़ा है कि यह बहुत ही असंभव है कि आप हाथ से विलय कर सकते हैं ताकि आप 'कमांड' या '-Xtheirs' विकल्प को रीबेस कमांड में जोड़ सकें। मुझे यकीन है कि आपको अंतिम परिणाम मास्टर रेफ के स्रोत से अलग होगा। – James
एक समाधान के लिए पूरी तरह से पढ़ें, लेकिन दुर्भाग्य से, Git क्लोन फैशन अनुरोध कर रहे हैं में काम नहीं करता: यहाँ एक अच्छा कैसे है। --depth पैरामीटर revisions की संख्या को commits की संख्या से सीमित करता है। एक क्लोन पैरामीटर नहीं है जो काम की मात्रा को सीमित करता है। आपकी स्थिति में, भले ही आपको पता चले कि फ़ाइल से अधिकतम 10 संशोधन अंतर थे जो रेपो में v3.0 और नवीनतम HEAD के बीच सबसे अधिक बदल गए हैं और --depth 10 का उपयोग करते हैं, फिर भी आप अधिकतर या संपूर्ण रेपो इतिहास प्राप्त कर सकते हैं। क्योंकि कुछ वस्तुओं में 10 संशोधन नहीं हो सकते हैं और आप रेपो में अपनी पहली उपस्थिति की शुरुआत में अपना इतिहास वापस ले लेंगे।
अब यह है कि आप क्या चाहते हैं: आपकी समस्या की कुंजी यह है कि आपको v3.0 और हाल ही में सबसे अधिक संदर्भ के बीच की आवश्यकता है।
git clone http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git --depth 10075 smaller_kernel_repocd smaller_kerenel_repogit log --oneline v3.0^..v3.0echo "02f8c6aee8df3cdc935e9bdd4f2d020306035dbe" > .git/info/graftsकुछ कर्नेल लॉग प्रविष्टियों के साथ कुछ समस्याएं प्राप्त करने के लिए: export GIT_AUTHOR_NAME="tmp" और export GIT_COMMITTER_NAME="tmp"
वहाँ आदमी पेज में के बारे में एक अच्छा चेतावनी है के बारे में git filter-branch भ्रष्टाचार अंक का पालन करते हुए इतिहास को फिर से लिखने ... इसलिए दुरुपयोग कि, अब git filter-branch चलाने के लिए और आराम से बैठकर प्रतीक्षा करें ... (और इंतजार की सुविधा देता है और इंतजार)
अब तुम सब कुछ साफ करने के लिए की जरूरत है:
git reflog expire --expire=now --all
git repack -ad # Remove dangling objects from packfiles
git prune # Remove dangling loose objects
इस प्रक्रिया में समय लग लेकिन बहुत जटिल नहीं है। उम्मीद है कि यह आपको हर समय बचाएगा जब आप लंबे समय तक उम्मीद कर रहे थे। इस बिंदु पर आप अनिवार्य रूप से लिनक्स-स्थिर.git repo से v3.0 के संशोधित इतिहास के साथ एक रेपो होगा।जैसे कि क्लोन पर --depth का उपयोग किया गया है, तो आपके पास रेपो पर समान प्रतिबंध हैं और आपके पास पहले से मौजूद इतिहास से पैच को संशोधित और भेजने में सक्षम होंगे। इसके चारों ओर तरीके हैं .. लेकिन यह अपने स्वयं के क्यू & ए
मैं पिछले कुछ चरणों का परीक्षण करने की प्रक्रिया में हूं, लेकिन git filter-branch ऑपरेशन अभी भी चल रहा है। मैं इस पोस्ट को किसी भी मुद्दे से अपडेट कर दूंगा, लेकिन मैं आगे बढ़ूंगा और इसे पोस्ट करूंगा ताकि अगर आप इसे स्वीकार्य पाते हैं तो आप इस प्रक्रिया को शुरू कर सकते हैं। जारी करने के लिए
अद्यतन
वर्कअराउंड (घातक: खाली अध्यक्ष < अनुमति नहीं>)। यह समस्या लिनक्स रेपो के प्रतिबद्ध इतिहास में एक समस्या के साथ उपजी है।
को git filter-branch आदेश बदलें:
git filter-branch --commit-filter '
if [ "$GIT_AUTHOR_EMAIL" = "" ];
then
GIT_AUTHOR_EMAIL="[email protected]";
GIT_AUTHOR_NAME='tmp'
GIT_COMMITTER_NAME='Me'
GIT_COMMITTER_EMAIL='[email protected]'
git commit-tree "[email protected]";
else
git commit-tree "[email protected]";
fi '
मुझे लगता है कि यह * संशोधन * और * प्रतिबद्ध * के बीच सख्ती से अंतर करने के लिए अधिक जटिल चीजें हैं। जबकि मुझे [औपचारिक अंतर] (http://stackoverflow.com/a/11792712/1127485) के बारे में पता है, 'गिट क्लोन - डीपथ
--depth पैरामीटर केवल एक नंबर ("संशोधन के संख्या निर्दिष्ट"), एक टैग नहीं हो रहा है।
संभव विचार (परीक्षण किया जाना):
आप क्रम में git describe हालांकि का उपयोग आप वर्तमान प्रधान से सबसे हाल ही टैग, साथ ही के बीच के लिए प्रतिबद्ध की संख्या प्राप्त करने सकता है टैग और HEAD कहा।
यदि वह "सबसे हालिया टैग" आपका टैग नहीं है, तो उस नवीनतम टैग द्वारा संदर्भित प्रतिबद्धता से शुरू होने वाली प्रक्रिया को बस दोहराएं, जब तक आपको अपना टैग नहीं मिलता है (उदाहरण के लिए v3.0 आपके मामले में)।
उन सभी प्रतिबद्ध संख्याओं का योग आपको git clone आदेश देने की गहराई देगा, बशर्ते आपका टैग आपके वर्तमान HEAD से पहुंच योग्य हो।
1 की गहराई तक टैग क्लोन करने के बारे में कैसे?
git clone --branch mytag0.1 --depth 1 https://example.com/my/repo.gitयह ** ** ** स्वीकृत उत्तर कैसे है? – tftd
कोई है जो पहले से ही एक क्लोन इस आदेश वर्तमान शाखा की नोक और टैग 5.6 के बीच प्रतिबद्ध की संख्या प्राप्त होगा के लिए:
$ git rev-list HEAD ^5.6 --count
407
मैं इस परियोजना को लागू करने में पाया गया गिटहब एपीआई का उपयोग करके पुन: सूची: https://github.com/cjlarose/github-rev-list
rev-list पर बहुत लंबा आदमी पृष्ठ इंगित करता है कि दृश्यों के पीछे बहुत कुछ चल रहा है। संभावित रूप से शाखाओं के माध्यम से काम करने के लिए कई अलग-अलग मार्ग हैं और आने और जाने में विलीन हो जाते हैं। (?) उपयोग के इस मामले कि हालांकि के लिए शायद ध्यान नहीं दिया जा सकता है
बनाने के @ n8henrie में थोड़ा और अधिक पूरा का जवाब है, तो आप --single-branch विकल्प जोड़ सकते हैं, इस तरह:
git clone --single-branch --branch mytag0.1 --depth 1 https://example.com/my/repo.git
इस में था आप केवल मिल इस विशेष टैग से संबंधित भंडार वस्तुएं, जो कि मेरे अनुभव में, कई मामलों में, बहुत अधिक जगह छोड़ती हैं।git-clone docs से:
- [नहीं-] एकल शाखा
क्लोन केवल इतिहास एक एकल शाखा की नोक के लिए अग्रणी है, या तो
--branchविकल्प या प्राथमिक शाखा दूरदराज केHEADअंक द्वारा निर्दिष्ट पर। परिणामस्वरूप भंडार में आगे लाने से शाखा के लिए रिमोट-ट्रैकिंग शाखा अपडेट हो जाएगी, इस विकल्प का उपयोग शुरुआती क्लोनिंग के लिए किया गया था। यदिHEADरिमोट पर किसी भी शाखा पर इंगित नहीं किया गया था तो--single-branchक्लोन बनाया गया था, कोई रिमोट-ट्रैकिंग शाखा नहीं बनाई गई है।
एक अतिरिक्त ध्यान दें: यदि आप एक ही कंप्यूटर में कोई अन्य फ़ोल्डर से एक स्थानीय रेपो क्लोनिंग कर रहे हैं, यह बजाय केवल फ़ोल्डर नाम निर्दिष्ट करने के file:// प्रोटोकॉल का उपयोग कर यह उल्लेख करने के लिए, आवश्यक है।
यह भी देखें [मैं एक गिट भंडार से पुराने इतिहास को कैसे हटा सकता हूं?] (Http://stackoverflow.com/questions/4515580/how-do-i-remove-the-old-history-from-a- गिट-रिपोजिटरी) – Alberto