Git के साथ गंदे इंडेक्स या अनटैक की गई फ़ाइलों की जाँच करना

Question

यदि मैं अपनी गिट रिपॉजिटरी में कोई भी परिवर्तन नहीं कर सकता हूं तो मैं कैसे जांच सकता हूं:

1. सूचकांक में परिवर्तन किया गया है लेकिन प्रतिबद्ध नहीं है
2. अनट्रैक फ़ाइलें

एक स्क्रिप्ट से?

git-status हमेशा जीआईटी संस्करण 1.6.4.2 के साथ शून्य वापस करने के लिए लगता है।

Comments

जीआईटी स्टेटस 1 तब वापस आएगा जब अनस्टेज्ड मॉडिफाइड फाइल्स हों। लेकिन सामान्य तौर पर, मुझे लगता है कि गिट टूल्स विशेष रूप से रिटर्न स्थिति के साथ पूरी तरह से नहीं हैं। ईजी गिट भिन्न रिटर्न 0 अंतर है या नहीं।

— intuited

@intuited: यदि आपको diffकमांड के सफल चलने के बजाय मतभेदों की उपस्थिति या अनुपस्थिति को इंगित करने की आवश्यकता है, तो आपको उपयोग करने की आवश्यकता है --exit-codeया --quiet। git कमांड आमतौर पर कमांड की सफलता को इंगित करने के लिए एक शून्य या गैर-शून्य निकास कोड को वापस करने के साथ बहुत सुसंगत हैं।

— सीबी बेली

@Charles बेली: हे महान, मैंने उस विकल्प को याद किया। धन्यवाद! मुझे लगता है कि मुझे ऐसा करने के लिए वास्तव में कभी ज़रूरत नहीं पड़ी, या मैंने शायद इसके लिए मैनपेज को स्कैन किया होगा। खुशी है कि तुम मुझे ठीक किया :)

— intuited

रॉबर्ट - यह समुदाय के लिए एक बहुत ही भ्रमित करने वाला विषय है (इससे कोई फर्क नहीं पड़ता है कि 'चीनी मिट्टी के बरतन का इस्तेमाल अलग-अलग संदर्भों में अलग-अलग तरीके से किया जाता है)। आपके द्वारा चुना गया उत्तर 2.5x गुना अधिक वोट वाले उत्तर की उपेक्षा करता है जो अधिक मजबूत है, और गिट डिजाइन का अनुसरण करता है। क्या आपने @ChrisJ का जवाब देखा है?

— माइक

@ रॉबर्ट - मुझे उम्मीद है कि आप अपने स्वीकृत उत्तर को बदलने पर विचार कर सकते हैं। आपके द्वारा चुना गया अधिक नाजुक नाजुक 'पोर्सिलेन' कमांड पर निर्भर करता है; वास्तविक सही उत्तर ( 2x भी upvotes के साथ) सही git 'प्लंबिंग' कमांड पर निर्भर करता है। इसका सही उत्तर मूल रूप से क्रिस जॉन्सन ने दिया था। मैं इसे उठाता हूं क्योंकि आज तीसरी बार मुझे इस पृष्ठ पर किसी को संदर्भित करना था, लेकिन मैं केवल उत्तर की ओर इशारा नहीं कर सकता, मैंने समझाया है कि स्वीकृत उत्तर उप-इष्टतम / सीमा रेखा गलत क्यों है। धन्यवाद!

— माइक

Answer 1

महान समय! मैंने कुछ दिन पहले इस बारे में एक ब्लॉग पोस्ट लिखी थी, जब मुझे पता चला कि अपने प्रॉम्प्ट में git स्टेटस की जानकारी कैसे जोड़ सकते हैं।

यहाँ मैं क्या कर रहा हूँ:

1. गंदी स्थिति के लिए:

   # Returns "*" if the current git branch is dirty.
   function evil_git_dirty {
     [[ $(git diff --shortstat 2> /dev/null | tail -n1) != "" ]] && echo "*"
   }

2. अनट्रैक की गई फ़ाइलों के लिए ( --porcelainध्वज को नोटिस करें git statusजो आपको अच्छा पार्स-सक्षम आउटपुट देता है):

   # Returns the number of untracked files
   
   function evil_git_num_untracked_files {
     expr `git status --porcelain 2>/dev/null| grep "^??" | wc -l` 
   }

यद्यपि git diff --shortstatयह अधिक सुविधाजनक है, आप git status --porcelainगंदी फ़ाइलों को प्राप्त करने के लिए भी उपयोग कर सकते हैं :

# Get number of files added to the index (but uncommitted)
expr $(git status --porcelain 2>/dev/null| grep "^M" | wc -l)

# Get number of files that are uncommitted and not added
expr $(git status --porcelain 2>/dev/null| grep "^ M" | wc -l)

# Get number of total uncommited files
expr $(git status --porcelain 2>/dev/null| egrep "^(M| M)" | wc -l)

नोट: 2>/dev/nullत्रुटि संदेशों को फ़िल्टर करता है ताकि आप इन आदेशों का उपयोग गैर-गिट निर्देशिकाओं पर कर सकें। (वे बस 0फ़ाइल की गणना के लिए लौट आएंगे ।)

संपादित करें :

यहाँ पोस्ट हैं:

अपने टर्मिनल प्रॉम्प्ट में Git स्थिति जानकारी जोड़ना

बेहतर Git- सक्षम शेल प्रॉम्प्ट

Comments

यह ध्यान देने योग्य है कि गिट बैश समापन एक शेल फ़ंक्शन के साथ आता है जो कि आप अपने प्रॉम्प्ट के साथ बहुत कुछ कर रहे हैं - __git_ps1। यदि आप रिबेस, एम-अप्लाई, मर्ज या बाइसेक्ट की प्रक्रिया में हैं, तो यह विशेष उपचार सहित शाखा नामों को दर्शाता है। और आप GIT_PS1_SHOWDIRTYSTATEअस्थिर परिवर्तन और मंचन परिवर्तनों के लिए तारांकन प्राप्त करने के लिए पर्यावरण चर सेट कर सकते हैं। (मुझे लगता है कि आप इसे अनकैप्ड फाइलों को इंगित करने के लिए भी प्राप्त कर सकते हैं, और आपको कुछ git-describeआउटपुट दे सकते हैं )

— कैस्केबेल

एक चेतावनी: git diff --shortstatएक गलत नकारात्मक देगा यदि परिवर्तन पहले से ही सूचकांक में हैं।

— मार्को टोपोलनिक

git status --porcelainबेहतर है, क्योंकि git diff --shortstatनव-निर्मित खाली फ़ाइलों को नहीं पकड़ा जाएगा। आप इसे किसी भी साफ काम के पेड़ में आज़मा सकते हैं:touch foo && git diff --shortstat

— कैम्पड्रेनैलिन

नहीं - चीनी मिट्टी के बरतन का मतलब है कि उत्पादन मनुष्यों के लिए है और आसानी से टूट जाता है !! @ChrisJohnsen का उत्तर देखें, जो सही रूप से स्थिर, स्क्रिप्ट के अनुकूल विकल्पों का उपयोग करता है।

— माइक

चीनी मिट्टी के बरतन विकल्प के बारे में गिट-स्टेटस मैन पेज से @ मायिक: "स्क्रिप्ट के लिए एक आसान-से-समांतर प्रारूप में आउटपुट दें। यह लघु आउटपुट के समान है, लेकिन गिट संस्करणों के पार और उपयोगकर्ता कॉन्फ़िगरेशन की परवाह किए बिना स्थिर रहेगा। "

— इसकी तदोपरांत

Answer 2

"स्क्रिप्टिंग" Git को मज़बूती से करने के लिए कुंजी 'प्लंबिंग' कमांड का उपयोग करना है।

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

दुर्भाग्य से 'रोज़' गित कमांड 'पोर्सिलेन' कमांड हैं, इसलिए अधिकांश गिट उपयोगकर्ता प्लंबिंग कमांड से परिचित नहीं हो सकते हैं। चीनी मिट्टी के बरतन और प्लंबिंग कमांड के बीच अंतर मुख्य गिट मैनपेज में किया जाता है ( उच्च-स्तरीय कमांड (चीनी मिट्टी के बरतन) और निम्न-स्तरीय कमांड (प्लंबिंग) शीर्षक वाले उपखंड देखें ।

---

अनियोजित परिवर्तनों के बारे में जानने के लिए, आपको git diff-indexकुछ अन्य ट्रीशिश (जैसे HEAD) के विरुद्ध इंडेक्स (और शायद काम करने वाले पेड़ के बिट्स की git diff-filesतुलना ) की आवश्यकता होगी, हो सकता है (इंडेक्स के खिलाफ काम करने वाले पेड़ की तुलना), और संभवतः git ls-files(सूची फ़ाइलें; उदाहरण के लिए सूची अनट्रेक्टेड) , अहस्ताक्षरित फ़ाइलें)।

(ध्यान दें कि नीचे दिए गए आदेशों में, HEAD --इसके बजाय इसका उपयोग किया जाता है , HEADअन्यथा यदि कोई फ़ाइल नाम की है तो आदेश विफल हो जाता है HEAD।)

यह जाँचने के लिए कि क्या एक भंडार ने परिवर्तनों का मंचन किया है (अभी तक प्रतिबद्ध नहीं) इसका उपयोग करें:

git diff-index --quiet --cached HEAD --

• यदि यह बाहर निकलता है 0तो कोई मतभेद नहीं थे ( 1मतलब अंतर थे)।

यह जाँचने के लिए कि क्या एक कार्यशील पेड़ में परिवर्तन हैं जिनका मंचन किया जा सकता है:

git diff-files --quiet

• बाहर निकलने का कोड git diff-index( 0== कोई मतभेद नहीं; 1== मतभेद) के समान है।

यह जाँचने के लिए कि क्या वर्क ट्री में इंडेक्स और ट्रैक की गई फ़ाइलों का संयोजन सम्मान के साथ बदलता है HEAD:

git diff-index --quiet HEAD --

• यह पिछले दो के संयोजन की तरह है। एक मुख्य अंतर यह है कि यह तब भी "कोई अंतर नहीं" रिपोर्ट करेगा यदि आपके पास काम के पेड़ में "पूर्ववत" है कि आपके पास एक परिवर्तन है (वापस सामग्री में हैं HEAD)। इसी स्थिति में, दो अलग-अलग कमांड "अंतर मौजूद" की रिपोर्ट लौटाएंगे।

आपने अनटैक की गई फ़ाइलों का भी उल्लेख किया। आपका मतलब हो सकता है "अनट्रैक और अनरिजर्व्ड", या आपका मतलब सिर्फ सादा "अनट्रैक" (अनदेखा फ़ाइलों सहित) हो सकता है। किसी भी तरह से, git ls-filesकाम के लिए उपकरण है:

"अनट्रैक" के लिए (यदि मौजूद हो तो अनदेखा फ़ाइलें शामिल होंगी):

git ls-files --others

"अनट्रैकड एंड अनइग्नोरड" के लिए:

git ls-files --exclude-standard --others

मेरा पहला विचार सिर्फ यह जांचना है कि क्या इन कमांड में आउटपुट है:

test -z "$(git ls-files --others)"

• यदि यह बाहर निकलता है, 0तो कोई भी फ़ाइल नहीं हैं। अगर इसके साथ बाहर निकलता है 1तो अनट्रैक फाइलें हैं।

एक छोटा सा मौका है कि यह असामान्य निकास से git ls-files"नो अनट्रैक फाइल्स" रिपोर्ट (उपरोक्त कमांड के गैर-शून्य निकास में दोनों परिणाम) का अनुवाद करेगा। थोड़ा और मजबूत संस्करण इस तरह दिख सकता है:

u="$(git ls-files --others)" && test -z "$u"

• विचार पिछले कमांड के समान है, लेकिन यह अप्रत्याशित त्रुटियों git ls-filesको बाहर फैलाने की अनुमति देता है। इस मामले में एक गैर-शून्य निकास का मतलब "अनट्रैक फाइल्स हैं" या इसका मतलब यह हो सकता है कि कोई त्रुटि हुई है। यदि आप चाहते हैं कि "त्रुटि" परिणाम "नहीं अनट्रैक फाइल्स" परिणाम के साथ संयुक्त है, तो इसका उपयोग करें test -n "$u"(जहां 0"कुछ अनट्रैक की गई फाइलें" का अर्थ है, और गैर-शून्य का मतलब है त्रुटि या "कोई अनट्रैक की गई फाइलें")।

एक अन्य विचार यह है कि --error-unmatchजब गैर-शून्य फ़ाइलें न हों तो गैर-शून्य निकास का उपयोग करें। यह "कोई 1त्रुटि नहीं हुई" (गैर-शून्य से बाहर निकलना, लेकिन शायद 128) के साथ "कोई अनकही फ़ाइलों" (बाहर निकलने ) को भ्रमित करने का जोखिम भी चलाता है । लेकिन 0बनाम 1बनाम शून्य-शून्य निकास कोड के लिए जाँच संभवतः काफी मजबूत है:

git ls-files --others --error-unmatch . >/dev/null 2>&1; ec=$?
if test "$ec" = 0; then
    echo some untracked files
elif test "$ec" = 1; then
    echo no untracked files
else
    echo error from ls-files
fi

उपरोक्त git ls-filesउदाहरणों में से कोई भी --exclude-standardआप ले सकते हैं यदि आप केवल अनअट्रैकड और अनरजिस्टर्ड फ़ाइलों पर विचार करना चाहते हैं।

Comments

मैं यह बताना चाहूंगा कि स्थानीय अनट्रैक की गई फाइलें git ls-files --othersदेता है , जबकि स्वीकृत उत्तर की सभी गैट रिपॉजिटरी के अंतर्गत आने वाली अनट्रैक की गई फाइलें देता है। मैं इनमें से कौन सा मूल पोस्टर नहीं चाहता था, लेकिन दोनों के बीच का अंतर दिलचस्प है। git status --porcelain

— एरिक ओ लेबिगॉट

@phunehehe: आप के साथ एक pathspec आपूर्ति की जरूरत है --error-unmatch। प्रयास करें (जैसे) git ls-files --other --error-unmatch --exclude-standard .(अनुगामी अवधि पर ध्यान दें, यह cwd को संदर्भित करता है; इसे कार्यशील पेड़ के शीर्ष-स्तरीय निर्देशिका से चलाएं)।

— क्रिस जॉन्सन

@ एफएस: बेमेल स्टेटमेंट (2) जानकारी के कारण कुछ "गलत सकारात्मक" से बचने git update-index -q --refreshके diff-indexलिए आपको पहले कुछ करने की आवश्यकता हो सकती है ।

— क्रिस जॉन्सन

मैं git update-indexजरूरत से काट लिया गया था ! यह महत्वपूर्ण है अगर कुछ संशोधन किए बिना फ़ाइलों को छू रहा है।

— नाकाबिल

@RobertSiemer "लोकल" से मेरा तात्पर्य आपकी वर्तमान निर्देशिका के तहत फाइलों से है , जो इसके मुख्य गिट रिपॉजिटरी से नीचे हो सकती है। --porcelainसमाधान सूचियों सभी ट्रैक न किए गए फ़ाइलों में पाया पूरे Git भंडार (ऋण Git नज़रंदाज़ फ़ाइलें), भले ही आप उसकी उप-में से एक के अंदर हैं।

— एरिक ओ लेबिगॉट

Answer 3

मान लें कि आप 1.7.0 या बाद में git पर हैं ...

इस पृष्ठ पर सभी उत्तरों को पढ़ने और कुछ प्रयोग करने के बाद, मुझे लगता है कि विधि है कि शुद्धता और संक्षिप्तता के सही संयोजन को हिट करती है:

test -n "$(git status --porcelain)"

जबकि git ट्रैक किए गए, अनदेखा, अनियंत्रित लेकिन बिना बताए के बीच बहुत सारी बारीकियों की अनुमति देता है, और इसी तरह, मेरा मानना ​​है कि विशिष्ट उपयोग मामला बिल्ड स्क्रिप्ट को स्वचालित करने के लिए है, जहां आप अपना चेकआउट साफ नहीं होने पर सब कुछ रोकना चाहते हैं।

उस स्थिति में, यह अनुकरण करने के लिए समझ में आता है कि प्रोग्रामर क्या करेगा: git statusआउटपुट को देखें और देखें। लेकिन हम दिखाने वाले विशिष्ट शब्दों पर भरोसा नहीं करना चाहते हैं, इसलिए हम --porcelain1.7.0 में पेश किए गए मोड का उपयोग करते हैं ; जब सक्षम किया जाता है, तो एक साफ निर्देशिका का कोई परिणाम नहीं होता है।

फिर हम test -nयह देखने के लिए उपयोग करते हैं कि कोई आउटपुट था या नहीं।

यदि कार्य निर्देशिका साफ़ है और यदि कोई परिवर्तन किए जाने हैं, तो यह कमांड 1 वापस आ जाएगी। आप बदल सकते हैं -nएक करने के लिए -zयदि आप विपरीत चाहते हैं। यह एक स्क्रिप्ट में एक कमांड के लिए इस का पीछा करने के लिए उपयोगी है। उदाहरण के लिए:

test -z "$(git status --porcelain)" || red-alert "UNCLEAN UNCLEAN"

यह प्रभावी रूप से कहता है "या तो कोई बदलाव नहीं किया जाना है या अलार्म बंद करना है"; यह एक-लाइनर आपके द्वारा लिखी गई स्क्रिप्ट के आधार पर एक if-statement के लिए बेहतर हो सकता है।

Comments

मेरे लिए अन्य सभी कमांड लिनक्स और खिड़कियों के बीच एक ही प्रतिनिधि पर अलग-अलग परिणाम दे रहे थे। इस कमांड ने मुझे दोनों में समान आउटपुट दिया।

— आदर्श

प्रश्न का उत्तर देने के लिए धन्यवाद और पर और कभी नहीं, स्पष्ट उत्तर प्रदान करने के लिए नहीं।

— नैट्स

मैन्युअल परिनियोजन स्क्रिप्ट के लिए, test -n "$(git diff origin/$branch)"स्थानीय कमिट्स को परिनियोजन में अनुमति देने से रोकने में मदद करने के लिए इसे संयोजित करें

— Erik Aronesty

Answer 4

वॉन के जवाब से एक कार्यान्वयन :

if [[ -n $(git status --porcelain) ]]; then echo "repo is dirty"; fi

Answer 5

इन जवाबों में से कुछ के माध्यम से एक नज़र थी ... (और * nix और विंडोज़ पर विभिन्न मुद्दे थे, जो मुझे एक आवश्यकता थी) ... निम्नलिखित पाया अच्छी तरह से काम किया ...

git diff --no-ext-diff --quiet --exit-code

* निक्स में निकास कोड की जाँच करने के लिए

echo $?   
#returns 1 if the repo has changes (0 if clean)

विंडो में निकास कोड की जाँच करने के लिए $

echo %errorlevel% 
#returns 1 if the repos has changes (0 if clean) 

से प्राप्त https://github.com/sindresorhus/pure/issues/115 साझा करने के लिए उस पोस्ट पर @paulirish के लिए धन्यवाद

Answer 6

क्यों नहीं git statusएक स्क्रिप्ट के साथ 'समझाया' :

• उस कमांड के आउटपुट का विश्लेषण करेगा
• आपको जो आवश्यक है, उसके आधार पर उपयुक्त त्रुटि कोड लौटाएगा

इस तरह, आप अपनी स्क्रिप्ट में उस 'बढ़ी हुई' स्थिति का उपयोग कर सकते हैं।

---

के रूप में 0xFE अपने में उल्लेख है उत्कृष्ट जवाब , git status --porcelainकिसी भी स्क्रिप्ट-आधारित समाधान में महत्वपूर्ण भूमिका निभाई है

--porcelain

स्क्रिप्ट के लिए आउटपुट को स्थिर, आसान-से-पार्स स्वरूप में दें।
वर्तमान में यह समान है --short output, लेकिन भविष्य में इसे स्क्रिप्ट के लिए सुरक्षित बनाने की गारंटी नहीं है।

Comments

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

— रॉबर्ट मुंटेनू

मैंने आपके सुझाव के आधार पर एक समाधान पोस्ट किया, हालाँकि मैं इससे बहुत संतुष्ट नहीं हूँ।

— रॉबर्ट मुंटेनू

Answer 7

एक DIY संभावना, 0xfe के सुझाव का पालन करने के लिए अद्यतन किया गया

#!/bin/sh
exit $(git status --porcelain | wc -l) 

जैसा कि क्रिस जॉन्सन ने कहा है , यह केवल Git 1.7.0 या नए पर काम करता है।

Comments

इसके साथ मुद्दा यह है कि आप मज़बूती से भविष्य के संस्करणों में स्ट्रिंग 'वर्किंग डायरेक्टरी क्लीन' की उम्मीद नहीं कर सकते हैं। - चीनी मिट्टी के बरतन ध्वज को पार्सिंग के लिए बनाया गया था, इसलिए एक बेहतर समाधान होगा: निकास $ (गिट्टी की स्थिति

— चीनी मिट्टी के

@ 0xfe - क्या आपको पता है कि --porcelainझंडा कब जोड़ा गया था? 1.6.4.2 के साथ काम नहीं करता है।

— राबर्ट मुन्तनु

@ रॉबर्ट: कोशिश git status --shortतो करो ।

— वॉनच

git status --porcelainऔर git status --shortदोनों को 1.7.0 में पेश किया गया था। --porcelainइसे विशेष रूप से git status --shortभविष्य में इसके प्रारूप को बदलने की अनुमति देने के लिए पेश किया गया था । इसलिए, git status --shortएक ही समस्या का सामना करना पड़ेगा क्योंकि git status('प्लंबिंग' कमांड नहीं है) आउटपुट किसी भी समय बदल सकता है।

— क्रिस जॉन्सन

@ क्रिस, पृष्ठभूमि की जानकारी के लिए धन्यवाद। मैंने इसे Git 1.7.0 के रूप में करने के सर्वोत्तम तरीके को प्रतिबिंबित करने के लिए उत्तर को अपडेट किया है।

— रॉबर्ट मुंटेनू

Answer 8

मुझे निर्माण में असफल होने के लिए अक्सर एक सरल तरीके की आवश्यकता होती है यदि निष्पादन के अंत में कोई भी संशोधित ट्रैक की गई फ़ाइलें या किसी भी अनट्रैक की गई फ़ाइलों को अनदेखा नहीं किया जाता है।

यह उन मामलों से बचने के लिए काफी महत्वपूर्ण है जहां निर्माण बचे हुए उत्पाद का निर्माण करता है।

अब तक, सबसे अच्छा कमांड जो मैंने समाप्त किया है वह इस तरह दिखता है:

 test -z "$(git status --porcelain | tee /dev/fd/2)" || \
     {{ echo "ERROR: git unclean at the end, failing build." && return 1 }}

यह थोड़ा जटिल लग सकता है और अगर किसी को एक छोटा संस्करण मिल जाए तो मैं सराहना करूंगा कि यह वांछित व्यवहार बनाए रखता है:

• कोई भी आउटपुट और सक्सेस एग्जिट कोड नहीं है, अगर इवनिंग क्रम में है
• यदि यह विफल रहता है तो बाहर निकलें कोड 1
• Stderr पर त्रुटि संदेश यह बताते हुए कि यह विफल क्यों है
• विफलता के कारण फ़ाइलों की प्रदर्शन सूची, फिर से stderr।

Answer 9

@ eduard-wirch का उत्तर काफी पूर्ण था, लेकिन जैसा कि मैं एक ही समय में दोनों की जांच करना चाहता था, यहां मेरा अंतिम संस्करण है।

        set -eu

        u="$(git ls-files --others)"
        if ! git diff-index --name-only --quiet HEAD -- || [ -z "${u:-}" ]; then
            dirty="-dirty"
        fi

जब सेट-ई या समकक्ष का उपयोग करके निष्पादित नहीं किया जाता है, तो हम इसके बजाय एक कर सकते हैं u="$(git ls-files --others)" || exit 1(या वापस आ सकते हैं यदि यह एक प्रयुक्त फ़ंक्शन के लिए काम करता है)

यदि आदेश ठीक से सफल हो जाता है, तो केवल untracked_files, सेट किया जाता है।

जिसके बाद, हम दोनों गुणों की जांच कर सकते हैं, और एक चर (या जो भी) निर्धारित कर सकते हैं।

Answer 10

यह पता लगाने के लिए एक अधिक शेल फ्रेंडली बदलाव है कि क्या रिपॉजिटरी में कोई भी अनट्रैक फाइल मौजूद है:

# Works in bash and zsh
if [[ "$(git status --porcelain 2>/dev/null)" = *\?\?* ]]; then
  echo untracked files
fi

यह एक दूसरी प्रक्रिया को कांटा नहीं करता है grep, और यदि आपको गिट रिपॉजिटरी में है या नहीं, तो इसके लिए चेक की आवश्यकता नहीं है। जो शेल प्रॉम्प्ट आदि के लिए आसान है।

Answer 11

आप भी कर सकते हैं

git describe --dirty

। यदि यह एक गंदा काम करने वाले पेड़ का पता लगाता है, तो यह अंत में "-डर्टी" शब्द को जोड़ देगा। के अनुसार git-describe(1):

   --dirty[=<mark>]
       Describe the working tree. It means describe HEAD and appends <mark> (-dirty by default) if
       the working tree is dirty.

। कैविएट: अनटैक की गई फ़ाइलों को "गंदा" नहीं माना जाता है, क्योंकि, जैसा कि मैनपेज बताता है, यह केवल काम करने वाले पेड़ की परवाह करता है।

Answer 12

इस धागे से जवाब का एक बेहतर संयोजन हो सकता है .. लेकिन मेरे लिए यह काम करता है ... अपने लिए .gitconfigके [alias]खंड ...

          # git untracked && echo "There are untracked files!"
untracked = ! git status --porcelain 2>/dev/null | grep -q "^??"
          # git unclean && echo "There are uncommited changes!"
  unclean = ! ! git diff --quiet --ignore-submodules HEAD > /dev/null 2>&1
          # git dirty && echo "There are uncommitted changes OR untracked files!"
    dirty = ! git untracked || git unclean

Answer 13

सबसे आसान स्वचालित परीक्षण जिसका उपयोग मैं गंदे अवस्था का पता लगाने के लिए करता / करती हूं : किसी भी तरह की परिवर्तन जिसमें अनट्रैक फाइलें शामिल हैं :

git add --all
git diff-index --exit-code HEAD

ध्यान दें:

• बिना add --all diff-indexअनपैक की गई फाइलों पर गौर नहीं करता।
• आम तौर पर, मैं git resetसब कुछ वापस करने के लिए त्रुटि कोड का परीक्षण करने के बाद चलाता हूं ।

Comments

सवाल विशेष रूप से "एक स्क्रिप्ट से" है ... यह केवल एक गंदे राज्य के परीक्षण के लिए सूचकांक को बदलने के लिए एक अच्छा विचार नहीं है।

— स्कॉटज

@ एससीओटीजे, जब यह समस्या हल करता है, तो सभी को जरूरी नहीं कि सूचकांक को संशोधित किया जाए या नहीं। स्वचालित नौकरी के मामले पर विचार करें जो संस्करण संख्या के साथ ऑटो-पैच स्रोतों के बारे में है और एक टैग बनाते हैं - आपको यह सुनिश्चित करने की आवश्यकता है कि बिल्कुल कोई अन्य स्थानीय संशोधन रास्ते में न रहें (चाहे वे सूचकांक में हों या नहीं)। अब तक, अनट्रैक फ़ाइलों सहित किसी भी परिवर्तन के लिए यह विश्वसनीय परीक्षण था ।

— uvsmtid

Answer 14

यहाँ सबसे अच्छा, सबसे साफ तरीका है। चयनित जवाब किसी कारण से मेरे लिए काम नहीं करता था, यह उन परिवर्तनों को नहीं उठाता था जो नई फाइलें थीं जो प्रतिबद्ध नहीं थीं।

function git_dirty {
    text=$(git status)
    changed_text="Changes to be committed"
    untracked_files="Untracked files"

    dirty=false

    if [[ ${text} = *"$changed_text"* ]];then
        dirty=true
    fi

    if [[ ${text} = *"$untracked_files"* ]];then
        dirty=true
    fi

    echo $dirty
}