मीनिंग ऑफ गिट चेकआउट डबल डैश


274

इस git कमांड में फ़ाइल नाम से पहले डबल डैश का क्या अर्थ है?

git checkout --ours -- path/to/file.txt
git checkout --theirs -- path/to/file.txt

क्या वे अनिवार्य हैं? के बराबर है?

git checkout --ours path/to/file.txt
git checkout --theirs path/to/file.txt

24
यह एक शैल अभिव्यक्ति है। देखें unix.stackexchange.com/questions/11376/…
iltempo

15
@ गिल्टी: यह गिट के लिए थोड़ा अलग है। गिट के लिए, यह पेड़ को रास्तों से अलग करता है, ऐसे मामलों में जहां पेड़ और रास्ते समान दिख सकते हैं।
डिट्रिच एप्प

@Dietrich_Epp। समझा। स्पष्टीकरण देने के लिए धन्यवाद।
iltempo

इसके अलावा stackoverflow.com/a/1192194/6309
VonC

3
यह एक डुप्लिकेट है, लेकिन यह डुप्लिकेट कम से कम googleable क्वेरी 'git डबल डैश' द्वारा है।
कंटक ०

जवाबों:


376

मान लीजिए कि मेरे पास path/to/file.txtमेरे गिट रिपॉजिटरी में एक फ़ाइल है, और मैं उस पर बदलाव वापस करना चाहता हूं।

git checkout path/to/file.txt

अब मान लीजिए कि फ़ाइल का नाम master...

git checkout master

ओह! इसके बदले शाखाओं को बदल दिया। जिस --पेड़ को आप चेक करना चाहते हैं, उससे अलग होने वाले पेड़ को अलग करना।

git checkout -- master

यह भी हमारी मदद करता है अगर कुछ फ्रीको ने -fहमारी रिपॉजिटरी नामक एक फ़ाइल को जोड़ा :

git checkout -f      # wrong
git checkout -- -f   # right

इसे गिट-चेकआउट में प्रलेखित किया गया है : तर्क विच्छेद


12
यह कई बैश कमांड के लिए सही है, न कि सिर्फ git कमांड्स के लिए, हाँ?
NHDaly

40
@NHDaly: हाँ, यह सच है। हालाँकि, एक शब्दावली नोट: "बैश" में केवल कुछ कमांड हैं (शायद 20 या तो), अधिकांश कमांड बैश से अलग कार्यक्रम हैं। यह वास्तव में POSIX मानक का हिस्सा --है जिसका उपयोग अन्य तर्कों से विकल्पों को अलग करने के लिए किया जा सकता है, इसलिए आप इसे कमांड पर देखेंगे ( cpऔर mvजो बैश का हिस्सा नहीं हैं)।
डिट्रीच एप्प

6
किसी भी विचार क्यों इस वाक्यविन्यास को checkoutकमांड प्रलेखन में ठीक से वर्णित नहीं किया गया है ?
टंगूपी

4
@DietrichEpp कई स्थानों पर, इसे checkoutकमांड के संभावित पैरामीटर की तरह सूचीबद्ध किया गया है, लेकिन कहीं भी प्रलेखन यह नहीं समझाता है कि यह क्या करता है या इसका उपयोग क्यों किया जाता है ... जो कि आखिरकार मुझे यहां लाया है।
क्रिस

7
@DietrichEpp सही है, लेकिन स्टैक ओवरफ्लो में आने से पहले सिंटैक्स (और उदाहरण) को पढ़ने के बाद, मुझे अभी भी समझ नहीं आया कि कोई क्यों उपयोग नहीं करना चाहेगा --। किसी के रूप में जो एक लिनक्स पृष्ठभूमि से नहीं आता है, यह स्पष्ट नहीं है कि वह क्या करता है। मेरे लिए, यह गिट के लिए एक वाक्यविन्यास विशिष्ट प्रतीत होता है, जिसमें इसके कार्यात्मक उद्देश्य का कोई विवरण नहीं है। मुझे लगता है कि अन्य विकल्पों की तरह एक संक्षिप्त विवरण देना बेहतर होगा, या कम से कम एक लाइनक्स मैन पेज का लिंक होगा ।
क्रिस

109

डबल डैश "-" का अर्थ है "कमांड लाइन के झंडे का अंत" अर्थात यह पूर्ववर्ती कमांड को यह बताने की कोशिश नहीं करता है कि कमांड लाइन विकल्पों के बाद क्या आता है।


2
स्पष्टता के लिए, gitइसमें इसका मतलब इससे अधिक है, क्योंकि इसका अर्थ यह भी है कि --शाखा नाम नहीं होने के बाद तर्क हो सकता है, और इससे पहले कि --फ़ाइल पथ नहीं हो सकता है , तर्क का अर्थ लगाता है।
जेम टेलर

0

ध्यान दें कि आपको जरूरत नहीं होगी, क्योंकि Git 2.5 (Q2 2015) a ' --' यदि आपके तर्क में वाइल्डकार्ड ( *) शामिल है

git <cmd> <revs> <pathspec>गलत लाइन वाले रास्तों को पकड़ने के लिए " " कमांड लाइन कन्वेंशन में मदद करने के लिए एक अनुमान है कि कमांड लाइन के बाद के हिस्से में सभी गैर-रेव मापदंडों को काम करने वाले पेड़ में फाइलों के नाम हैं, लेकिन इसका मतलब है कि git grep $str -- \*.cहमेशा " " होना चाहिए " --" से असंतुष्ट , क्योंकि कोई भी व्यक्ति कोई फ़ाइल नहीं बनाएगा, जिसका नाम शाब्दिक रूप से तारांकित-डॉट-देखें है।

Git 2.5 यह बताने के लिए कि किसी वाइल्डकार्ड स्ट्रिंग के साथ उपयोगकर्ता को एक pathspec देने की संभावना है, यह घोषित करने के लिए विधायी को खो देता है

git checkout 'a*'
# same as
git checkout -- 'a*'

Duy Nguyen ( ) द्वारा प्रतिबद्ध 28fcc0b (02 मई 2015) देखें । (द्वारा विलय Junio सी Hamano - - में प्रतिबद्ध 949d167 , 19 मई 2015)nguyenlocduy
gitster

pathspec: --वाइल्डकार्ड का उपयोग करने पर " " की आवश्यकता से बचें

जब --कमांड लाइन से " " की कमी होती है और एक कमांड रेव्स और पाथ दोनों को ले सकता है, तो विचार यह है कि यदि एक तर्क को एक विस्तारित SHA-1 और एक पथ दोनों के रूप में देखा जा सकता है, तो " --" आवश्यक है या जारी रखने के लिए मना कर देता है।
यह वर्तमान में इस प्रकार लागू है:

  • (१) यदि कोई तर्क उलटा है, तो उसका वर्कट्री में मौजूद नहीं होना चाहिए
  • (२) और, यह कार्यक्षेत्र में मौजूद होना चाहिए
  • (3) और, " --" आवश्यक है।

ये नियम शाब्दिक रास्तों के लिए काम करते हैं, लेकिन जब गैर-शाब्दिक रास्ते में शामिल होते हैं, तो उपयोगकर्ता को लगभग हमेशा " --" जोड़ने की आवश्यकता होती है क्योंकि यह विफल होता है (2) और (1) वास्तव में शायद ही कभी मिलता है ( *.cउदाहरण के लिए " ले" , (1) अगर वहाँ एक रेफरी है जिसका नाम " *.c") है।

यह पैच किसी भी वैध ( *) वाइल्डकार्ड pathspec "वर्कट्री में मौजूद है" पर विचार करके नियमों को थोड़ा संशोधित करता है ।
नियम बन जाते हैं:

  • (1) यदि कोई arg एक Rev है, तो यह या तो वर्कट्री में मौजूद होना चाहिए या एक मान्य वाइल्डकार्ड pathspec नहीं होना चाहिए।
  • (२) और, यह या तो वर्कट्री में मौजूद है या वाइल्डकार्ड पाथसेप है
  • (3) और, " --" आवश्यक है।

नए नियमों के साथ, --वाइल्डकार्ड पाथसेप में शामिल होने पर " " अधिकांश समय की आवश्यकता नहीं होती है।


Git 2.26 (Q1 2020) के साथ, संशोधन और pathspec को अलग-अलग बताने के लिए तर्क को अलग कर दिया गया है ताकि बैकस्लैश-बच गए ग्लोब विशेष वर्णों की गिनती "वाइल्डकार्ड्स pathspec" में न हो।

जेफ किंग ( ) द्वारा देखें कमिट 39e21c6 (25 जनवरी 2020 )(द्वारा विलय Junio सी Hamano - - में प्रतिबद्ध 341f8a6 , 12 फ़र 2020)peff
gitster

verify_filename(): "वाइल्डकार्ड्स पाथस्पेक्स" नियम में बैकस्लैश संभालते हैं

रिपोर्टेड-बाय: डेविड बर्स्ट्रम
साइन-ऑफ-बाय: जेफ किंग

प्रतिबद्ध 28fcc0b71a ( pathspec: --वाइल्डकार्ड का उपयोग करने पर " " की आवश्यकता से बचें , 2015-05-02) की अनुमति दी:

git rev-parse '*.c'

डबल-डैश के बिना।

लेकिन वाइल्डकार्ड्स की जांच के लिए यह जिस नियम का उपयोग करता है वह वास्तव में किसी भी विशेष के लिए दिखता है।
यह पूरी तरह से उदार है, क्योंकि इसका मतलब है कि एक पैटर्न जो वास्तव में किसी भी वाइल्डकार्ड मिलान नहीं करता है, जैसे " a\b", एक पथ प्रदर्शक माना जाएगा।

यदि आपके पास डिस्क पर ऐसी कोई फ़ाइल है, तो संभवतः यह वही है जो आप चाहते थे।
लेकिन अगर आप नहीं करते हैं, तो परिणाम भ्रामक हैं: " there's no such path a\b" कहने के बजाय , हम चुपचाप इसे एक ऐसे मार्ग के रूप में स्वीकार करेंगे जो बहुत संभावना है कि कुछ भी नहीं (या कम से कम आपके द्वारा इच्छित उद्देश्य) से मेल नहीं खाता।
इसी तरह, रास्ते की तलाश में " a\*b" खोज का विस्तार नहीं करता है; इसे केवल एक प्रविष्टि मिलेगी, " a*b"।

यह प्रतिबद्ध नियम को केवल तभी ट्रिगर करने के लिए स्विच करता है जब ग्लोब मेटाचैटरर्स खोज का विस्तार करेगा, जिसका अर्थ है कि उन दोनों मामलों में अब एक त्रुटि की रिपोर्ट होगी (आप अभी भी " --" का उपयोग करके अवहेलना कर सकते हैं , निश्चित रूप से; हम सिर्फ DWIM विधर्मी को कस रहे हैं)।

( DWIM: मेरा क्या मतलब है )

ध्यान दें कि हमने 28fcc0b71a में मूल विशेषता का परीक्षण बिल्कुल नहीं किया ।
तो यह पैच न केवल इन कोने के मामलों के लिए परीक्षण करता है, बल्कि मौजूदा व्यवहार के लिए एक प्रतिगमन परीक्षण भी जोड़ता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.