क्या "git fetch --tags" में "git fetch" शामिल है?

Question

एक अच्छा और सरल प्रश्न है - "git fetch" का कार्य एक सख्त उप-समुच्चय है git fetch --tags?

यानी अगर मैं दौड़ता हूं git fetch --tags, तो क्या इसके तुरंत git fetchबाद सीधे दौड़ने का कोई कारण है ?

के बारे में git pullऔर क्या git pull --tags? वही स्थिति?

Comments

Git 1..9 / 2.0 (Q1 2014) शुरू करना, इसका उत्तर हां में होगा । देखें नीचे मेरा उत्तर

— VonC

संपादक के लिए जिसने एक संपादन के साथ "मेरे पाठ को ठीक किया" - एक जरूरी नहीं कि एक हाइफ़न या एक संक्षिप्त नाम के बाद पूंजीकरण हो, इसलिए आपका संपादन व्याकरणिक रूप से गलत था, यही कारण है कि मैंने इसे अस्वीकार कर दिया।

— davidA

Answer 1

नोट: के साथ शुरू Git 1.9 / 2.0 (क्यू 1 2014) , git fetch --tagsटैग को हासिल करेगा के अलावा क्या विकल्प के बिना एक ही कमांड लाइन से लाई जाती हैं।

माइकल Haggerty (mhagger) द्वारा प्रतिबद्ध c5a84e9 देखें :

पहले, --tagsरिंचेक को निर्दिष्ट करने के लिए " " विकल्प को समान माना जाता था

refs/tags/*:refs/tags/*

कमांड लाइन पर; विशेष रूप से, इसने remote.<name>.refspecकॉन्फ़िगरेशन को अनदेखा कर दिया।

लेकिन यह भी अन्य संदर्भ प्राप्त करने में कठिनाई के बिना टैग लाने के लिए बहुत उपयोगी है, जबकि ऐसा नहीं है है काफी टैग लाने के लिए सक्षम होने के लिए उपयोगी के अलावा अन्य संदर्भ।
तो बाद के करने के लिए इस विकल्प के शब्दार्थ को बदलें।

यदि कोई उपयोगकर्ता केवल टैग प्राप्त करना चाहता है , तो स्पष्ट रीस्पेक निर्दिष्ट करना अभी भी संभव है:

git fetch <remote> 'refs/tags/*:refs/tags/*'

कृपया ध्यान दें कि 1.8.0.3 से पहले प्रलेखन " fetch --tags" व्यवहार के इस पहलू के बारे में अस्पष्ट था ।
प्रतिबद्ध f0cb2f1 (2012-12-14) fetch --tagsने प्रलेखन को पुराने व्यवहार से जोड़ा ।
यह नए व्यवहार (देखें Documentation/fetch-options.txt) से मेल खाने के लिए दस्तावेज़ में बदलाव करता है ।

अनुरोध करें कि सभी टैगों को रिमोट से प्राप्त किया जाए और इसके अलावा जो भी प्राप्त हो रहा है ।

---

चूंकि Git 2.5 (Q2 2015) git pull --tagsअधिक मजबूत है:

देखें 19d122b प्रतिबद्ध द्वारा पॉल टैन ( pyokagan) , 13 मई 2015
^{(द्वारा विलय Junio सी Hamano - gitster- में cc77b99 प्रतिबद्ध , 22 मई 2015)}

pull: --tagsकोई मर्ज उम्मीदवारों के मामले में त्रुटि को दूर करें

चूंकि 441ed41 (" git pull --tags": बेहतर संदेश के साथ त्रुटि।, 2007-12-28, Git 1.5.4+), किसी भी मर्ज किए गए उम्मीदवारों को वापस नहीं करने पर git pull --tagsएक अलग त्रुटि संदेश प्रिंट करेगा git-fetch:

It doesn't make sense to pull all tags; you probably meant:
       git fetch --tags

ऐसा इसलिए है क्योंकि उस समय, git-fetch --tagsकिसी भी कॉन्फ़िगर किए गए रीस्पेक को ओवरराइड करेगा, और इस तरह कोई मर्ज किए गए उम्मीदवार नहीं होंगे। इस प्रकार त्रुटि संदेश भ्रम को रोकने के लिए पेश किया गया था।

हालांकि, बाद से c5a84e9 ( fetch --tags: लाने टैग के अलावा अन्य सामान, 2013-10-30, Git 1.9.0+), git fetch --tagsकिसी भी कॉन्फ़िगर किया गया refspecs के अलावा टैग लाने होगा।
इसलिए, यदि कोई मर्ज उम्मीदवारों की स्थिति नहीं होती है, तो ऐसा इसलिए नहीं है क्योंकि --tagsसेट किया गया था। जैसे, यह विशेष त्रुटि संदेश अब अप्रासंगिक है।

भ्रम को रोकने के लिए, इस त्रुटि संदेश को हटा दें।

---

Git के साथ 2.11+ (Q4 2016) git fetchतेज है।

जेफ किंग ( ) द्वारा प्रतिबद्ध 5827a03 (13 अक्टूबर 2016) देखें । ^{(द्वारा विलय Junio सी Hamano - - में प्रतिबद्ध 9fcd144 , 26 अक्टू 2016)}peff
gitster

fetch: has_sha1_fileटैग के लिए "त्वरित" का उपयोग करें

जब हम रिमोट का उपयोग करते हैं, जिसमें कई टैग होते हैं जो हमारे द्वारा अनुसरण की जा रही शाखाओं के लिए अप्रासंगिक होते हैं, तो हम जाँच करते समय बहुत अधिक चक्रों को बर्बाद करते थे यदि किसी टैग द्वारा इंगित की गई वस्तु (जिसे हम लाने नहीं जा रहे हैं!) हमारे रिपॉजिटरी में मौजूद है। बहुत ध्यान से।

यह पैच ऐसे मामलों में गति के लिए सटीकता का बलिदान करने के लिए HAS_SHA1_QUICK का उपयोग करना सिखाता है, ऐसे मामलों में जहां हम एक साथ पुनरावर्ती हो सकते हैं।

यहां शामिल पूर्ण स्क्रिप्ट से परिणाम हैं, जो ऊपर वर्णित एक स्थिति के समान है:

Test            HEAD^               HEAD
----------------------------------------------------------
5550.4: fetch   11.21(10.42+0.78)   0.08(0.04+0.02) -99.3%

यह केवल उस स्थिति के लिए लागू होता है जहां:

1. आपके पास reprepare_packed_git()महंगा बनाने के लिए क्लाइंट की तरफ बहुत सारे पैक हैं (सबसे महंगा हिस्सा एक अनसोल्ड सूची में डुप्लिकेट ढूंढ रहा है, जो वर्तमान में द्विघात है)।
2. आपको सर्वर साइड पर बड़ी संख्या में टैग की आवश्यकता होती है जो ऑटो-फॉलोइंग के लिए उम्मीदवार हैं (यानी, क्लाइंट के पास नहीं है)। हर एक पैक डायरेक्टरी के री-रीड को ट्रिगर करता है।
3. सामान्य परिस्थितियों में, ग्राहक उन टैगों का स्वतः अनुसरण करेगा और एक बड़े लाने के बाद, (2) अब सच नहीं होगा।
   लेकिन अगर वे टैग इतिहास की ओर इशारा करते हैं जो ग्राहक से अलग हो गए हैं, तो वह कभी भी ऑटो-फॉलो नहीं करेगा, और वे उम्मीदवार इसे हर भ्रूण पर प्रभावित करेंगे।

---

Git 2.21 (फरवरी 2019) एक प्रतिगमन शुरू की है जब लगता है config remote.origin.fetchहै नहीं डिफ़ॉल्ट ( '+refs/heads/*:refs/remotes/origin/*')

fatal: multiple updates for ref 'refs/tags/v1.0.0' not allowed

---

Git 2.24 (Q4 2019) एक और अनुकूलन जोड़ता है।

मसाया सुजुकी ( ) द्वारा प्रतिबद्ध b7e2d8b (15 सितंबर 2019) देखें । ^{( जूनियो सी हमानो द्वारा विलय - - इसमें १ डी df बी ० एफडी , ० Oct अक्टूबर २०१ ९)}draftcode
gitster

fetch: oidsetतेजी से देखने के लिए चाहते हैं OIDs रखने के लिए उपयोग करें

git fetchयदि ग्राहक विज्ञापित टैग 'OID' पहले से ही भ्रूण के अनुरोध के OID सेट में है, तो जाँच के दौरान ।
यह जाँच एक लीनियर स्कैन में की जाती है।
एक रिपॉजिटरी के लिए जिसमें बहुत सारे रेफ हैं, इस स्कैन को दोहराने में 15+ मिनट लगते हैं।

इसे गति देने के लिए, oid_setअन्य रेफल्स के लिए OIDs बनाएं ।

Comments

Git-list में यह थ्रेड git fetch <remote> <branch>ऑटो-फॉलो टैग्स के व्यवहार में संशोधन करने की संभावना पर चर्चा करता है (क्योंकि यह पहले से ही रिमोट-ट्रैकिंग AGAINST मूल इरादों को अपडेट करता है): public-inbox.org/git/…

— akostis

@ankostis दिलचस्प: जैसा कि जूनियो ने public-inbox.org/git/… में उल्लेख किया है , "पुराने व्यवहार पर वापस जाने से इस धागे में चर्चा की जा रही समस्या का समाधान करने के लिए एक विकल्प हो सकता है।" (लेकिन वे ऐसा नहीं करेंगे: public-inbox.org/git/... )

— VonC

क्या यह संभव होगा कि Git के लिए एंड-यूज़र के लिए अधिक अनावश्यक जटिलता को उजागर करना, सिंटैक्स-हैवी कमांड्स की आवश्यकता होती है, जो आम ऑपरेशन करने के लिए हैक्स से मिलता जुलता है? मुझे नहीं लगता कि इंटर्नल के पर्याप्त ज्ञान की अभी तक आवश्यकता है।

— जॉन फैंटास्टिको

@ जॉनफैन्सटैटो मैं उस दृष्टिकोण को समझ सकता हूं। मैंने इससे पहले देखा है: news.ycombinator.com/item?id=16587496 । या hackernoon.com/… ("Git कमांड डेटा भंडारण पर सिर्फ एक टपका हुआ अमूर्त है।")

— VonC

@Vadorequest धन्यवाद। मैंने जवाब अपडेट कर दिया है और मेलिंग सूची पर नज़र रखेगा

— VonC

Answer 2

नोट: यह उत्तर केवल git v1.8 और पुराने के लिए मान्य है।

इसमें से अधिकांश अन्य उत्तरों और टिप्पणियों में कहा गया है, लेकिन यहां संक्षिप्त विवरण दिया गया है:

• git fetchसभी शाखा प्रमुखों (या दूरस्थ द्वारा निर्दिष्ट सभी। config विकल्प), सभी उनके लिए आवश्यक हैं, और सभी टैग जो इन शाखाओं से उपलब्ध हैं। ज्यादातर मामलों में, सभी टैग इस तरह से उपलब्ध हैं।
• git fetch --tagsसभी टैग प्राप्त करते हैं, सभी उनके लिए आवश्यक हैं। यह शाखा प्रमुखों को अपडेट नहीं करेगा , भले ही वे उन टैगों से पहुंच योग्य हों जो कि प्राप्त किए गए थे।

सारांश: यदि आप वास्तव में पूरी तरह से अद्यतित होना चाहते हैं, तो केवल भ्रूण का उपयोग करके, आपको दोनों करना होगा।

यह "दो बार धीमा" भी नहीं है, जब तक कि आप कमांड-लाइन पर टाइप करने के मामले में मतलब नहीं करते हैं, जिस स्थिति में उपनाम आपकी समस्या को हल करते हैं। दोनों अनुरोधों को बनाने के लिए अनिवार्य रूप से कोई उपरि नहीं है, क्योंकि वे अलग-अलग जानकारी मांग रहे हैं।

Comments

आपके कमेंट के लिए धन्यवाद। मैं एक उच्च-विलंबता नेटवर्क पर साइगविन में गिट चला रहा हूं - यह दो बार धीमा है जब या तो (लगभग 1 सेकंड) लाने के लिए कुछ भी नहीं है।

— २१:०५ पर davidA

ओह वाह। क्या गिट-रिमोट कोई बेहतर काम करता है? स्रोत को संक्षेप में देखने से मुझे लगता है कि यह केवल एक कॉल कर सकता है - लेकिन मुझे पूरी तरह से यकीन नहीं है कि यह ऑन-ब्रांच टैग नहीं लेगा। ईमानदारी से मुझे पता नहीं है कि मैंने कभी कोई टैग नहीं देखा है। जिन चीज़ों से मैं खींचता हूँ, एक ही रास्ता है कि अगर मैं इतनी देर तक इंतजार करूँ तो मैं एक रखरखाव रिलीज़, एक सुविधा रिलीज़ और पुरानी रिलीज़ के रखरखाव को बंद करने से चूक गया।

— Cascabel

मुझे लगता है कि मुद्दा यह है कि 'git fetch' केवल ट्रैक की गई शाखाओं पर टैग लाती है । हमारे पास एक स्क्रिप्ट है जो उपयोगकर्ताओं को एक कार्यशील शाखा का चयन करने की अनुमति देती है, इसलिए डिफ़ॉल्ट रूप से कई शाखाएं हैं जो वर्तमान में किसी व्यक्ति द्वारा ट्रैक नहीं की जाती हैं।

— davidA

मैंने अभी तक git-

— Remote

ध्यान दें कि git remote updateवास्तव में git fetchऔर के लिए एक विकल्प नहीं है git fetch --tags। git remote updateजो मौजूदा टैग बदल गए हैं उन्हें अपडेट नहीं करेंगे, हालाँकि यह नए टैग में लाएगा। केवल git fetch --tagsपहले से मौजूद टैग ही अपडेट होंगे।

— २12

Answer 3

इसका जवाब मैं खुद देने जा रहा हूं।

मैंने निर्धारित किया है कि एक अंतर है। "git fetch --tags" सभी टैग में ला सकता है, लेकिन यह किसी भी नए संचार में नहीं लाता है!

यह पता चला है कि ऐसा करने के लिए पूरी तरह से "अप टू डेट" होना चाहिए, अर्थात मर्ज के बिना "गिट पुल" को दोहराया जाए:

$ git fetch --tags
$ git fetch

यह शर्म की बात है, क्योंकि यह दोगुनी धीमी है। यदि केवल "git fetch" के पास ऐसा करने का विकल्प होता है जो वह सामान्य रूप से करता है और सभी टैग में लाता है।

Comments

दिलचस्प है, मुझे ऐसा अनुभव नहीं हुआ (शायद इसलिए कि मेरे रेपो मेरे टेस्ट के समय तक थे।) +1

— वॉनसी

एक ' git remote update myRemoteRepo' के बारे में कैसे : कि दूरस्थ सामग्री और टैग लाएगा?

— वॉनसी

मैं git fetchहर समय करता हूं और यह लगातार किसी भी नए कमिट और किसी नए टैग को खींचता है । Git का कौन सा संस्करण चल रहा है?

— टिम विशेर

FTR, 'git रिमोट अपडेट myRemoteRepo' अच्छी तरह से काम नहीं करता है - ऐसा नहीं लगता है कि 'git fetch && git fetch --tags' क्या करता है, विशेष रूप से बाद के मर्ज का कोई प्रभाव नहीं पड़ता है।

— davidA

@TimVisher git fetchउन टैग्स को नहीं लेगा जो किसी शाखा के कमिट लॉग में नहीं हैं। jQuery UI उदाहरण के लिए रिलीज़ टैग पर ऐसा करता है। हम git checkout -b temp-branchअपनी रिलीज़ करते हैं, रिलीज़ के लिए आवश्यक फ़ाइलों को जोड़ते हैं, संस्करण अपडेट करते हैं, आदि, git commit -m "1.10.x" ; git tag 1.10.x; git push --tagsफिर हम अपनी स्थानीय अस्थायी शाखा को हटा देते हैं। कोई दूरस्थ शाखा नहीं है जो उस टैग तक पहुंचती है, और git fetchइसे कभी डाउनलोड नहीं करेगी।

— 21

Answer 4

यहाँ सामान्य समस्या यह है कि git fetchयह लाया जाएगा +refs/heads/*:refs/remotes/$remote/*। यदि इनमें से किसी भी कमिट में टैग हैं, तो वे टैग भी लाए जाएंगे। हालाँकि अगर रिमोट पर किसी भी शाखा द्वारा टैग उपलब्ध नहीं हैं, तो उन्हें नहीं लाया जाएगा।

--tagsविकल्प के लिए refspec स्विच +refs/tags/*:refs/tags/*। आप दोनों को हड़पने के लिए कह सकते हैं git fetch। मुझे पूरा यकीन है कि आप केवल git fetch && git fetch -tनिम्न कमांड का उपयोग करेंगे:

git fetch origin "+refs/heads/*:refs/remotes/origin/*" "+refs/tags/*:refs/tags/*"

और यदि आप इस रेपो के लिए इसे डिफ़ॉल्ट बनाना चाहते हैं, तो आप डिफ़ॉल्ट फ़िंच में दूसरा रीस्पेक जोड़ सकते हैं:

git config --local --add remote.origin.fetch "+refs/tags/*:refs/tags/*"

इससे इस रिमोट fetch =के .git/configलिए दूसरी लाइन जुड़ जाएगी ।

---

मैंने एक परियोजना के लिए इसे संभालने के तरीके की तलाश में कुछ समय बिताया। मैंने ये ढूंढ निकाला।

git fetch -fup origin "+refs/*:refs/*"

मेरे मामले में मुझे ये सुविधाएँ चाहिए थीं

• रिमोट से सभी हेड्स और टैग्स को पकड़ें ताकि रिफस्पेक का उपयोग करें refs/*:refs/*
• +Refspec से पहले गैर-फास्ट-फ़ॉर्वर्ड वाली स्थानीय शाखाओं और टैग को ओवरराइट करें
• जरूरत पड़ने पर वर्तमान में ओवर राइटिंग शाखा की जाँच करें -u
• रिमोट में मौजूद शाखाएं और टैग हटाएं -p
• और ज़बरदस्ती करना -f

Comments

इसका उत्तर होना चाहिए।

— Redolent

+1 के लिए " --tagsविकल्प refspec को स्विच करता है +refs/tags/*:refs/tags/*"। हालांकि, man git-fetchलगता है कि refspec अग्रणी के बिना निर्दिष्ट करने के लिए +( refs/tags/*:refs/tags/*)।

— दिमित्री मिन्कोवस्की

remote.origin.fetchचूक +refs/heads/*:refs/remotes/origin/*, यानी +संस्करण, है ना? (इसका मतलब है कि, उत्पत्ति / शाखा को अधिलेखित कर दिया जाएगा, कोई फर्क नहीं पड़ता कि मूल / शाखा अभी स्थानीय रूप से कहां है।)

— रॉबर्ट सिएमर

... और लेखन के समय, हाल ही में पहले से ही सब कुछ के अलावाgit --tags टैग प्राप्त कर रहे थे । देखें @VonC का जवाब।

— रॉबर्ट सेमर

Answer 5

ज्यादातर स्थितियों में, git fetchआपको वही करना चाहिए जो 'दूरस्थ रिपॉजिटरी से कुछ भी नया हो' और इसे अपनी स्थानीय शाखाओं में विलय किए बिना अपनी स्थानीय कॉपी में डाल दें। ' git fetch --tagsबिल्कुल ऐसा करता है, सिवाय इसके कि नए टैग के अलावा कुछ भी नहीं मिलता है।

इस मायने में, git fetch --tagsकिसी भी तरह से सुपरसेट नहीं है git fetch। यह वास्तव में इसके विपरीत है।

git pullबेशक, एक के लिए एक आवरण के अलावा कुछ भी नहीं है git fetch <thisrefspec>; git merge। यह अनुशंसा की जाती है कि जंप करने से पहले आपको मैनुअल git fetchआईएनजी और git mergeआईएनजी करने की आदत हो git pullक्योंकि यह आपको यह समझने में मदद करता git pullहै कि पहली जगह में क्या कर रहा है।

यह कहा जा रहा है, रिश्ता बिल्कुल वैसा ही है जैसा कि है git fetch। git pullका सुपरसेट है git pull --tags।

Comments

"git पुट git pull --tags का सुपरसेट है" - लेकिन ... 'git fetch' 'git fetch --tags' का superset नहीं है इसलिए संबंध बिल्कुल समान नहीं है ...?

— दविद्या

बस इस सवाल मिला ... अच्छी तरह से, मुझे लगता है कि git pullकरता है नहीं मिलता है सभी टैग लेकिन मौजूदा शाखा प्रमुखों से केवल उन पहुंचा जा सकता। हालाँकि, git pull --tagsसभी टैग प्राप्त करते हैं और स्पष्ट रूप से इसके समकक्ष होते हैं git fetch --tags।

— आर्किमिडिक्स

Answer 6

git fetch upstream --tags

बस ठीक काम करता है, इसे केवल नए टैग मिलेंगे और कोई अन्य कोड आधार नहीं मिलेगा।

Comments

upstreamआम तौर पर कहा जाता है origin। मुझे लगता upstreamहै कि GitHub द्वारा उपयोग किया जाने वाला एक नाम है। किसी भी मामले में, उपयोग करने का नाम वह है जिसे दिखाया गया है git remote।

— फैबियो का कहना है कि