2017-01-30 4 views
5

मुझे डॉटफाइल प्रबंधित करने के लिए एक मौजूदा निर्देशिका ($HOME) में एक गिट रेपो क्लोन करने की आवश्यकता है। मैं एक नंगे क्लोन कर रहा हूं और इसे पुन: कॉन्फ़िगर कर रहा हूं क्योंकि मुझे मौजूदा अशुद्ध कार्य निर्देशिका में क्लोन करने की आवश्यकता है। यह काम करता है, हालांकि मुझे लगता है कि git status पहले उपयोग पर फ़िल्टर चलाने की कोशिश करता है। ऐसा क्यों करता है और मैं इसे कैसे रोक सकता हूं?'गिट स्टेटस' फ़िल्टर क्यों चलाता है?

इस प्रयास करें:

# create a test repo 
mkdir test && cd test 
git init 
echo hello > hello.txt 
git add . 
git commit -m 1 
echo 'hello.txt filter=foo diff=bar' > .gitattributes 
git add . 
git commit -m 2 

# clone it bare and configure it 
mkdir ../test2 && cd ../test2 
git clone --bare ../test .git 
git config core.bare false 
git config core.logallrefupdates true 
git reset 
git checkout . 
git config filter.foo.clean foo 
git config filter.foo.smudge foo 
git config diff.bar.textconv bar 

यह borks

$ git status 
error: cannot run foo: No such file or directory 
error: cannot fork to run external filter 'foo' 
error: external filter 'foo' failed 
On branch master 
nothing to commit, working tree clean 

यह

$ git status 
On branch master 
nothing to commit, working tree clean 
इसके अलावा

नहीं, शुरू में जल्दी जल्दी में git status कई बार कर रही है (यानी git status; git status; git status) कई उपज कर सकते हैं करता है असफलता। कभी-कभी

जहां तक ​​मैं much reading द्वारा पुष्टि कर सकता हूं, फ़िल्टर केवल फाइलों को चेक आउट करते समय ही चलाना चाहिए।

तो git status क्यों उन्हें चलाता है?

+0

आपका 'गिट-वर्जन' क्या है? –

+0

गिट संस्करण 2.11.0 – starfry

+0

संयोग से, मैं इस तरह से डॉट-फाइलों का प्रबंधन नहीं करता (और नहीं)। इसके बजाए, मेरे पास मेरी होम निर्देशिका में 'डॉटफाइल' नामक एक गिट निर्देशिका है, जो एक सामान्य गैर-नंगे पेड़ है, और फिर मैं सिमलिंक '। जो भी' डॉटफाइल/जो भी 'से सिमलिंक करता हूं। – torek

उत्तर

2

विचार यह है कि केवल चेकइन/चेकआउट के दौरान चलने वाले फ़िल्टर white lie में से कुछ हैं। यह फिल्टर को और अधिक स्पष्ट करने के लिए है।

वास्तव में, हालांकि, फिल्टर चलाने जब सूचकांक और काम पेड़ के बीच फ़ाइलों को ले (और साथ ही Git के लिए पर्याप्त रूप से आधुनिक संस्करण में, जब git show में --path= विकल्प और git cat-file और git hash-object रूप में अच्छी तरह से अनुरोध किया: इन में से कुछ हैं सीधे भंडार से stdout, या stdin से भंडार में संक्रमण)। यह अधिकतर चेकइन/चेकआउट समय के बराबर है। लेकिन git status में इंडेक्स के कैश पहलू के कारण भी विशेष छूट है।

प्रदर्शन कारणों से, गिट जानना चाहता है कि वर्क-पेड़ में कोई भी फ़ाइल इंडेक्स में संस्करण के संबंध में "गंदे" हो सकती है या नहीं। Git मानता है कि stat मूल्य st_mtime है, जो आम तौर पर एक दूसरे संकल्प है, इस उद्देश्य के लिए इस्तेमाल किया जा सकता: यदि फ़ाइल की st_mtime समय -इस काम पेड़ किसी सहेजे गए st_mtime से अधिक उम्र के प्रवेश है इंडेक्स एंट्री में, फिर इंडेक्स एंट्री अद्यतित है और "साफ" है: इंडेक्स में क्या है, स्वच्छ फिल्टर इत्यादि लागू करने के बाद, वर्क-पेड़ में क्या होता है।

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

यदि दो बार टिकट समान हैं, तो कार्य-वृक्ष प्रविष्टि अनिश्चित है। (गिट ने यह "बेहद साफ" कहा है, हालांकि "बेहद गंदे" समान रूप से सटीक होगा।)

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

जब तक, आप इसे st_mtime स्टेट फ़ील्ड के संकल्प के भीतर नहीं करते हैं। उस स्थिति में, इंडेक्स एंट्री "रैसीली क्लीन" को हवा देती है और गिट को फिर से प्रयास करना पड़ता है। यह वही है जो आप यहां देख रहे हैं।

(ध्यान दें, वैसे, कि git status रन दो डिफ: सूचकांक को HEAD से एक है, और सूचकांक से एक काम-पेड़ से ऐसा नहीं है कि दूसरे diff कि सूचकांक के कैश पहलू से बेहद लाभ की द।। सूचकांक अब भी जानकारी भी स्टोर कर सकते हैं के बारे में uncached फ़ाइलों और निर्देशिकाओं!)


कुछ stat कॉल उप दूसरा परिशुद्धता देते हैं, लेकिन विभिन्न कारणों के लिए, सूचकांक/कैश प्रविष्टि केवल 1 संग्रहीत करता है किसी भी तरह से संकल्प समय टिकट, एन ormally।

इस पर अधिक (0) अधिक देखें, the racy-git.txt file in the technical documentation देखें।

+0

ग्रेट स्पष्टीकरण! यह भी बताता है कि 'hello.txt' स्पर्श करें 'गिट स्थिति' फ़िल्टर को क्यों चलाता है। और यह बताता है कि फ़ाइल टाइमस्टैम्प बदलने के बीच का समय और स्थिति जांच बहुत कम (<1s) के बीच फिर से क्यों चलती है। इस स्पष्टीकरण को देखते हुए, मुझे लगता है कि फ़िल्टर को चलाने से रोकने का कोई तरीका नहीं है (मेरे मामले में, फ़िल्टर क्रिप्टो कुंजी प्रदान किए जाने तक विफल हो जाएंगे)। इस मामले में, क्या मेरा काम-आसपास 'नींद 1 और गिट स्थिति और>/dev/null' सबसे अच्छा मैं उम्मीद कर सकता हूं ...? – starfry

+0

वह कामकाज काम करना चाहिए। मुझे नहीं पता कि आप इन चीजों को पहली जगह क्यों एन्क्रिप्ट कर रहे हैं, हालांकि। – torek

+0

निजी कुंजी, एपीआई कुंजी, आदि। मैं केवल प्रति फ़ाइल आधार पर संवेदनशील चीजों को क्रिप्ट करता हूं। – starfry

संबंधित मुद्दे