एक समस्या को ठीक करना चाहते हैं जहां मेरे पास अब एक ही नाम के साथ 2 निर्देशिका पथ हैं, बस पूंजीकरण में भिन्न है। क्योंकि, मैंने एक बार की बात है, निर्देशिका का नाम बदलकर लोअरकेस कर दिया।

मैं फ़ोल्डर दृश्य में सूचीबद्ध केवल एक फ़ोल्डर/निर्देशिका देखता हूं, रूट में कोई अन्य फाइल और फ़ोल्डर नहीं देता है। "someproject"/"src"

हालांकि, परिवर्तन करते समय मुझे प्रतिबद्ध करने के लिए फाइलों के 2 सेट दिखाई देते हैं।

Src/somefile.txt
src/somefile.txt

मैं रेपो से Src फ़ोल्डर और सामग्री को कैसे हटाऊं?

  • क्या मैं बैकअप " प्रतिबद्ध, धक्का?
git
2
Jason Foglia 7 जिंदा 2021, 22:45

2 जवाब

सबसे बढ़िया उत्तर

निर्देशिका को गिट से हटाने के लिए, लेकिन फाइल सिस्टम नहीं

git rm -r --cached folderNameToRemove

निर्देशिका को .gitignore में जोड़ें, और उसके बाद एक git पुश करना याद रखें।

इसी तरह के परिदृश्यों के लिए, इस शानदार धागे की जांच करें

2
nobalG 8 जिंदा 2021, 19:15

nobalG का उत्तर अच्छा है

यदि आप दौड़ते हैं:

git rm -r --cached src
git add src

आपको जाने के लिए अच्छा होना चाहिए (git status से पुष्टि करें)। आपको .gitignore में कुछ भी जोड़ने की आवश्यकता नहीं है। आपको वास्तव में git add कुछ भी करने की आवश्यकता नहीं हो सकती है।

इस उत्तर के साथ समस्या यह है कि यह सिर्फ एक नुस्खा है; यह आपको इस बारे में कुछ नहीं बताता कि अगली बार आपको क्या करना है, आपको विभिन्न समस्याएं हैं।

लंबा

सबसे पहले, समस्या को ठीक से परिभाषित करते हैं। हमें निम्नलिखित पर ध्यान देने की आवश्यकता है:

  • Git स्टोर कमिट, फ़ाइलें नहीं। यानी, जब आप git checkout या git कमिट चलाते हैं, तो आपके द्वारा डील की जाने वाली स्टोरेज की इकाई , प्रतिबद्ध है। यह सच है कि में फ़ाइलें शामिल हैं, लेकिन यह एक पैकेज डील है। (टुकड़ों में काम करने के कुछ अटपटे तरीके हैं, जिन्हें हम थोड़ी देर में समझेंगे; वे विशेष मामलों के लिए उपयोगी हैं।)

  • किसी भी प्रतिबद्धता के सभी भाग केवल पढ़ने के लिए हैं। जिसमें सभी संग्रहीत फ़ाइलें शामिल हैं। वे एक फ्रोजन-फॉर-ऑल-टाइम, संपीड़ित प्रारूप में संग्रहीत हैं। प्रत्येक फ़ाइल की सामग्री को हर दूसरी संग्रहीत फ़ाइल के विरुद्ध भी डी-डुप्लिकेट किया जाता है। यह महत्वपूर्ण है क्योंकि हर कमिट हर फाइल की एक पूरी कॉपी स्टोर करता है, लेकिन डी-डुप्लीकेशन के साथ, इसका मतलब है कि ज्यादातर कमिट ज्यादातर अपनी लगभग सभी फाइलों को हर दूसरे कमिट के साथ शेयर करते हैं। तथ्य यह है कि फाइलें केवल-पढ़ने के लिए सक्षम होती हैं: किसी संग्रहीत फ़ाइल को बदलना करना सचमुच असंभव है, इसलिए यदि प्रतिबद्ध X की फ़ाइल F1 को प्रतिबद्ध Y की फ़ाइल F2 के समान सामग्री की आवश्यकता है, तो यह पूरी तरह से उचित है उन्हें वास्तव में उसी संग्रहीत सामग्री का उपयोग करने के लिए।

  • आप जिन फ़ाइलों को देखते हैं और उन पर काम करते हैं वे Git में नहीं हैं Git में हैं फ़ाइलें वे नहीं हैं जो आप देखें और उस पर/के साथ काम करें। यह पिछले आइटम का प्रत्यक्ष परिणाम है। किसी दिए गए कमिट के अंदर संग्रहीत फ़ाइलें इस रूप में होती हैं कि गिट के अलावा कुछ भी नहीं पढ़ सकता है, और सचमुच कुछ भी नहीं—यहां तक ​​कि गिट भी नहीं—उन्हें आंशिक रूप से अधिलेखित कर सकता है, या तो आंशिक रूप से या पूरी तरह। इसका मतलब यह है कि जो फाइलें में Git हैं, वे किसी भी वास्तविक कार्य को करने के लिए पूरी तरह से बेकार हैं। तो गिट ऐसा करने की कोशिश नहीं करता है। जब आप काम करने/के साथ काम करने के लिए एक प्रतिबद्धता चुनते हैं, तो गिट प्रतिबद्धता की फाइलों को बाहर एक कार्य क्षेत्र में कॉपी करता है, जिसे हम आपका कार्यशील वृक्ष कहते हैं। em> या कार्य-वृक्ष

अब जब हम समझ गए हैं कि जिन फ़ाइलों को आप देख सकते हैं और उनके साथ काम कर सकते हैं, वे Git में नहीं हैं, और Git में जो फ़ाइलें हैं वे एक विशेष Git-only रूप में हैं, अब हम समझ सकते हैं कि यहाँ क्या हो रहा है। जब Git फ़ाइलों को संग्रहीत कर रहा होता है, तो ये फ़ाइलें फ़ोल्डर में नहीं होती हैं और लगभग-मनमाने नाम हो सकते हैं। Git प्रतिबद्ध में, हमारे पास src या Src नाम का कोई फ़ोल्डर नहीं है, जो somefile.txt नाम की फ़ाइल संग्रहीत करता हो। इसके बजाय, हमारे पास बस src/somefile.txt नाम की एक फ़ाइल है, जिसमें एक स्लैश है।1 और—यही हमारी समस्या की कुंजी है— ये नाम हमेशा केस संवेदी होते हैं, ताकि एक कमिट में src/somefile.txt और Src/somefile.txt, दोनों को दो अलग-अलग फाइलों के रूप में आसानी से समाहित किया जा सके। एक कमिटमेंट में readme.md और README.md, इत्यादि दोनों शामिल हो सकते हैं।

2

यदि आप किसी विशिष्ट Mac या Windows सिस्टम पर हैं, तो आपकी नियमित फ़ाइलें केस-संरक्षित लेकिन केस-संवेदी होती हैं। यह वास्तव में फ़ाइल-सिस्टम-विशिष्ट है, और एक macOS माउंटेबल डिस्क सेट करना आसान है जिसमें फ़ाइलें केस-संवेदी होती हैं, ताकि आप readme.md और< दोनों को कर स्टोर कर सकें। /em> README.md। MacOS पर ऐसा करने के तरीके के लिए मेरा उत्तर यहां देखें। विंडोज़ पर, आप एक वीएम सेट अप कर सकते हैं और लिनक्स चला सकते हैं; मैं विंडोज का उपयोग नहीं करता इसलिए मेरे पास इसके लिए कोई डिब्बाबंद प्रक्रिया नहीं है।


1तकनीकी रूप से, फ़ाइलों के प्रतिबद्ध संस्करण आंतरिक रूप से एक फ़ोल्डर जैसी संरचना का उपयोग करते हैं; वह स्थान जो फ़ोल्डरों को समतल कर देता है वह है Git का index। लेकिन आप वैसे भी कमिट्स के साथ सीधे काम नहीं कर सकते हैं: आप गिट के इंडेक्स में मौजूदा कमिट्स को पढ़ते हैं, और गिट के इंडेक्स में नए कमिट्स का निर्माण करते हैं, और यहाँ फ़ाइल नामों में शाब्दिक रूप से स्लैश शामिल हैं। तो हम यह भी कह सकते हैं कि फ़ाइल नामों में स्लैश हैं।

2Mac उपयोगकर्ता उन Windows उपयोगकर्ताओं पर हँस सकते हैं जो aux.txt नाम की फ़ाइलें नहीं बना सकते, क्योंकि Mac पर aux.txt बनाना आसान है। लेकिन मैक उपयोगकर्ताओं के पास अन्य समस्याएं हैं: उदाहरण के लिए, फ़ाइल नाम agréable को स्पेलिंग करने के दो तरीके हैं और उनमें से केवल एक मैक पर काम करता है। हालांकि यह कभी-कभी एक अच्छी बात होती है—हो सकता है कि हमारे पास दो भिन्न फाइलें न हों जो एक ही नाम की लगती हों—यह बिल्कुल एक ही तरह की इंटरऑपरेबिलिटी समस्याओं के साथ आती है।


MacOS पर समस्या का मामला सेट करना

चूंकि मेरे पास यहां एक मैक काम है, इसलिए मैं यह बता सकता हूं कि हम एक समस्या का मामला कैसे सेट करते हैं। हम एक नए, पूरी तरह से खाली भंडार के साथ शुरू करते हैं:

sh-3.2$ cd ~/tmp && mkdir case && cd case && git init
Initialized empty Git repository in /Users/torek/tmp/case/.git/
sh-3.2$ mkdir Dir && touch Dir/file && giit add Dir/file && git commit -m initial
[master (root-commit) 07ed87d] initial
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 Dir/file
sh-3.2$ mv Dir dir
sh-3.2$ echo some contents > dir/file

अब, अब तक हमने Git में ही जो कुछ भी किया है, एक प्रारंभिक खाली कमिट बनाया गया है जिसमें Dir/file नाम की एक फ़ाइल है। हालांकि, पिछले दो आदेशों ने macOS को हमारे कार्य क्षेत्र—हमारे कार्य-वृक्ष—का नाम बदलने के लिए Dir, प्रारंभिक-अपरकेस, dir, लोअरकेस, और पुट को संशोधित करने के लिए कहा। दी गई फ़ाइल में कुछ सामग्री। ls चलाने से पता चलता है कि OS ने वास्तव में वर्क-ट्री डायरेक्टरी का नाम बदल दिया था, लेकिन Git जानता है कि इस फाइल सिस्टम पर, dir/file और Dir/file दोनों काम करते हैं उसी सामान्य फ़ाइल को पढ़ें या लिखें। इसलिए:

sh-3.2$ ls
dir
sh-3.2$ cat dir/file
some contents
sh-3.2$ cat Dir/file
some contents

आप हमारे द्वारा किए गए अपडेट देख सकते हैं। परंतु:

sh-3.2$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   Dir/file

no changes added to commit (use "git add" and/or "git commit -a")

Git जानता है कि dir/file और Dir/file दोनों एक ही फाइल को एक्सेस करने के लिए काम करते हैं। इसके अलावा, गिट जानता है कि हमारी अंतिम प्रतिबद्धता में एक खाली Dir/file था। Git मानता है, इस वजह से, कि हम फ़ाइल के नाम की पिछली स्पेलिंग रखना चाहते हैं: Dir/file। (ध्यान दें कि नाम में स्लैश के साथ पूरा नाम है: कोई फ़ोल्डर नहीं हैं, बस फ़ाइलें हैं।)

गहरा गोता लगाना: Git का सूचकांक और core.ignorecase

यहां कई परस्पर जुड़े हुए टुकड़े शामिल हैं:

  • सबसे पहले, जब हम कुछ प्रतिबद्ध चेक आउट करते हैं, तो Git एक डेटा संरचना बनाता है जिसे Git विभिन्न रूप से इंडेक्स, या स्टेजिंग क्षेत्र कहता है, या—इन दिनों विरले ही—कैश। ये तीन नाम दर्शाते हैं कि यह बात कितनी महत्वपूर्ण है, या यह तथ्य कि "सूचकांक" बहुत अच्छा नाम नहीं है, या शायद दोनों।

    मैं गिट की अनुक्रमणिका को आपकी प्रस्तावित अगली प्रतिबद्धता के रूप में सारांशित करना चाहता हूं। मंचन क्षेत्र के रूप में यही इसकी भूमिका है। लेकिन यह पूरी तरह से पूर्ण नहीं है, जैसा कि हम एक पल में देखेंगे। फिर भी, यहां मुख्य विचार यह है कि जब आप पहली बार कुछ विशेष प्रतिबद्धताओं की जांच करते हैं, तो गिट प्रतियां सभी प्रतिबद्ध फाइलों को इसकी अनुक्रमणिका में को कर देता है।2 index—प्रस्तावित अगला कमिट — अब वर्तमान कमिट से मेल खाता है। यदि और जब आप परिवर्तन करते हैं, तो आपको अद्यतन फ़ाइल (फ़ाइलों) को अनुक्रमणिका में कॉपी करने के लिए Git प्राप्त करना होगा, और यहीं से git add आता है।

    याद रखें, अनुक्रमणिका में फ़ाइल का पूरा नाम होता है, जो फ़ॉरवर्ड स्लैश के साथ पूर्ण होता है। यह सब डेटा फ़ाइलों में रखा जाता है—वर्तमान में .git/index और शायद .git निर्देशिका में कुछ अतिरिक्त फ़ाइलें—जिन्हें आपके OS द्वारा प्रबंधित नहीं किया जा रहा है, बल्कि Git द्वारा प्रबंधित किया जा रहा है। इसलिए वे Git पर निर्भर हैं, और Git का कहना है कि ये फ़ाइल नाम है केस संवेदनशील हैं, इससे कोई फर्क नहीं पड़ता कि क्या चल रहा है। इसलिए सूचकांक readme.md और README.md, या दोनों dir/file और Dir/file दोनों को स्टोर कर सकता है।

  • इस बीच, आपके कार्य-वृक्ष या कार्यशील वृक्ष में आपकी सभी फ़ाइलें हैं, जो प्रयोग करने योग्य रूप में विस्तारित हैं। लेकिन अगर आपका OS इन्हें केस-इनसंवेदनशील मानता है, तो आप readme.md और README.md दोनों को यहां स्टोर नहीं कर पाएंगे। आप dir/file और Dir/file दोनों को स्टोर नहीं कर पाएंगे। आपका OS dir और Dir को एकल फ़ोल्डर नाम और readme.md और README.md दोनों को एकल फ़ाइल नाम के रूप में मानता है। उन्हें>. तो तथ्य यह है कि गिट की प्रतिबद्धता यहां दो नाम रख सकती है, लेकिन आपके ओएस की फाइल सिस्टम नहीं कर सकती, हमारी समस्याओं का कारण बनती है।

  • अंत में, जब Git ऊपर दिए गए उदाहरण में git init समय पर Git रिपॉजिटरी सेट करता है, उदाहरण के लिए- Git आपके फाइल सिस्टम की जांच करता है कि क्या यह केस को नजरअंदाज करता है। यदि आपका OS मामले को अनदेखा करता है, ताकि यह समस्या उत्पन्न हो सके, तो Git core.ignorecase को true पर सेट करता है:

    sh-3.2$ git config --get core.ignorecase
    true
    

    Git इसका उपयोग "जानने" के लिए करता है कि Dir/file और dir/file, Git से भिन्न होते हुए, आपके होस्ट OS के फ़ाइल सिस्टम के समान हैं।


2

  • फ़ाइल का नाम, फ़ॉरवर्ड स्लैश के साथ पूर्ण;
  • फ़ाइल का मोड, सामान्यतः या तो 100644 (पढ़ें/लिखें) या 100755 (पढ़ें/लिखें लेकिन निष्पादन योग्य भी);
  • एक ब्लॉब हैश आईडी, जो फ़ाइल की सामग्री के लिंक की तरह काम करता है, पहले से ही डी-डुप्लिकेट और आंतरिक गिट प्रारूप में; तथा
  • झंडे और अन्य आंतरिक कैश डेटा गिट को आपके कार्य-पेड़ में क्या है इसका ट्रैक रखने में मदद करने के लिए।

चूंकि सामग्री वास्तव में कहीं और है, इसलिए अनुक्रमणिका में फ़ाइल की सही प्रतिलिपि नहीं होती है। हालाँकि, प्रतिलिपि प्रबंधन सभी स्वचालित है। इसका मतलब यह है कि यदि संभव हो तो (यदि सामग्री कुछ मौजूदा प्रतिबद्ध फ़ाइल की नकल करती है) तो इंडेक्स कॉपी फ़ाइल की एक कॉपी की तरह काम करता है।

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


Git कैसे उपयोग करता है core.ignorecase

तो, ऊपर हमारे सेटअप में, हम:

  1. मैक या विंडोज केस-असंवेदनशील सिस्टम पर एक नया खाली रिपोजिटरी बनाया, जहां हमारे पास README.md और readme.md दोनों फाइलें नहीं हो सकती हैं, और हमारे पास दोनों नहीं हो सकते हैं Dir/file और dir/file. यदि हमारे पास Dir (अपरकेस) नाम की एक निर्देशिका है और हम dir/another बनाने का प्रयास करते हैं, तो सिस्टम इसके बजाय Dir/another बनाएगा।

    यह गिट की समस्या नहीं है, लेकिन गिट को इससे निपटना है।

  2. एक खाली Dir/file बनाया और प्रतिबद्ध किया। यह अब एक कमिट के अंदर है। इसे कभी नहीं बदला जा सकता है! वह प्रतिबद्धता, जब तक वह मौजूद है, उसमें उस पथ का नाम है, उस विशेष आवरण के साथ।

  3. Dir का नाम बदलकर dir करने के लिए कुछ OS-साइड टूल (macOS पर सादा mv, मुझे यकीन नहीं है कि आप विंडोज़ पर क्या उपयोग करेंगे) का उपयोग किया।

होस्ट फ़ाइल सिस्टम की केस-असंवेदनशील प्रकृति के कारण, जब हमने रिपॉजिटरी बनाई तो Git ने ही core.ignorecase को true पर सेट कर दिया। अब हम Git से झूठ कह सकते हैं और कह सकते हैं कि हमारा OS इन्हें अलग मामलों के रूप में मानता है। यह सच नहीं है! लेकिन हम अस्थायी रूप से जानबूझकर Git से झूठ कर सकते हैं। अगर चीजें गलत होती हैं, तो हम जिम्मेदार होंगे: ऐसा तब तक न करें जब तक कि आप जिम्मेदारी लेने को तैयार न हों।

sh-3.2$ echo some contents > dir/file
sh-3.2$ git status --short
 M Dir/file
sh-3.2$ git config core.ignorecase false
sh-3.2$ git status --short -uall
 M Dir/file
?? dir/file

(पहली पंक्ति एक दोहराव है, लेकिन क्योंकि मैंने > का उपयोग किया है, मैं इसे जितना चाहे दोहरा सकता हूं—यह फ़ाइल को मिटा देता है और इसमें some contents पढ़ने वाली एक पंक्ति डालता है)।

यहाँ, मैंने आउटपुट को छोटा करने के लिए git status --short का उपयोग किया है। M इंगित करता है कि कार्य-वृक्ष प्रति को संशोधित किया गया है। Git से झूठ बोलने से पहले, Git जाँचता है और देखता है कि dir/file मौजूद है, पता कि यह इंडेक्स Dir/file से मेल खाता है, और उनका मिलान करता है। एक बार जब मैं गिट से झूठ बोलता हूं, हालांकि, कुछ दिलचस्प होता है:

  • गिट का मानना ​​​​है कि एक Dir/file है। वह यह मानकर उस फ़ाइल को खोलने का प्रयास करता है कि उसे dir/file नहीं मिलेगा। लेकिन इसे dir/file मिलता है। यह इस dir/file की तुलना उसके विचार से करता है—Dir/file—और देखता है कि यह अलग है। तो अब Git कहता है कि फ़ाइल संशोधित (कार्य-वृक्ष में M) है।

  • Git dir नाम की डायरेक्टरी / फोल्डर को स्पॉट करता है, उसे पढ़ता है, और file नाम की फाइल ढूंढता है। पथ dir/file Git की अनुक्रमणिका में नहीं है, इसलिए Git का कहना है कि यह फ़ाइल अनट्रैक है (यह दोहरा प्रश्न चिह्न है)।

मैं अब git add dir/file कर सकता हूं:

sh-3.2$ git add dir/file
sh-3.2$ git status --short
 M Dir/file
A  dir/file

गिट ने लोअरकेस नाम का उपयोग करके dir/file को अपनी अनुक्रमणिका में कॉपी किया। फ़ाइल की इस प्रति में सामग्री some contents है। git status आउटपुट अब इसे नई फ़ाइल के रूप में दिखाता है। ऐसा इसलिए है क्योंकि वर्तमान प्रतिबद्धता में कोई dir/file नहीं है; इसमें केवल एक Dir/file (विभिन्न सामग्री के साथ) है।

मैं अब एक नई प्रतिबद्धता बना सकता हूं। इस नई प्रतिबद्धता में Dir/file—जो अभी भी खाली है—और dir/file, सामग्री some contents दोनों शामिल हैं:

sh-3.2$ git commit -m 'add lowercase version with content'
[master 793d32c] add lowercase version with content
 1 file changed, 1 insertion(+)
 create mode 100644 dir/file
sh-3.2$ git show HEAD:Dir/file
sh-3.2$ git show HEAD:dir/file
some contents
sh-3.2$ git ls-tree -r HEAD
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    Dir/file
100644 blob f70d6b139823ab30278db23bb547c61e0d4444fb    dir/file

यहाँ blob लाइनें Git के कहने का तरीका है कि दो फाइलें हैं। दो फाइलों के तरीके हैं 100644 (पढ़ें/लिखें लेकिन निष्पादित नहीं) और बड़ी बदसूरत हैश आईडी हैं कि कैसे गिट सामग्री को डी-डुप्लिकेट करता है; फ़ाइल के नाम दाईं ओर दिखाई देते हैं। प्रत्येक "फ़ोल्डर" में क्या है यह दिखाने के लिए -r विकल्प git ls-tree की आवश्यकता है (फुटनोट 1 भी देखें: यदि यह इस तथ्य के लिए नहीं थे कि अनुक्रमणिका फ़ोल्डरों को समतल कर देती है, Git एक खाली फ़ोल्डर को स्टोर करने में सक्षम होगा, लेकिन क्योंकि इंडेक्स अपना काम करता है, गिट नहीं कर सकता)।

अब जबकि मैंने यह प्रतिबद्ध कर दिया है, यह जमे हुए राज्य—दो अलग-अलग नाम-मामलों के साथ—हमेशा के लिए मौजूद है, या कम से कम, जब तक यह दूसरी प्रतिबद्धता मौजूद रहती है। मैं ऐसा करने में सक्षम था, यहां तक ​​​​कि केस-असंवेदनशील मैक फाइल सिस्टम पर, गिट से झूठ बोलने की चाल के माध्यम से।

core.ignorecase को पुनर्स्थापित करने से पहले मैं अब एक आखिरी चाल कर सकता हूं:

sh-3.2$ git rm --cached Dir/file
rm 'Dir/file'
sh-3.2$ git status --short
D  Dir/file
sh-3.2$ ls
dir
sh-3.2$ ls dir
file

मैं वास्तव में पहले से ही core.ignorecase को पुनर्स्थापित कर सकता था, क्योंकि git rm --cached को फैंसी केस ट्रिक्स करने की आवश्यकता नहीं है: यह हमेशा गिट की अनुक्रमणिका से प्रविष्टियों को हटा रहा है, और वे प्रविष्टियां हमेशा केस संवेदनशील होती हैं। लेकिन मैंने सोचा कि मैं इसे यहां इस तरह दिखाऊंगा। आइए core.ignorecase को वापस उसी तरह से रखें जैसा कि होना चाहिए, और परिणाम को प्रतिबद्ध करें:

sh-3.2$ git config core.ignorecase true
sh-3.2$ git commit -m 'remove uppercase Dir/file'
[master c5edc17] remove uppercase Dir/file
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 Dir/file
sh-3.2$ git status
On branch master
nothing to commit, working tree clean

मैंने अपनी इच्छित सामग्री के साथ एक सही प्रतिबद्ध किया है, और अब मेरे पास एक प्रतिबद्धता है जिसे इस मैक पर सही तरीके से उपयोग किया जा सकता है, यहां तक ​​​​कि केस-असंवेदनशील फ़ाइल सिस्टम में भी। मध्य प्रतिबद्धता, जिसमें Dir/file और dir/file दोनों हैं, किसी सामान्य Windows या Mac सेटअप पर सही ढंग से उपयोग नहीं किया जा सकता है—लेकिन क्योंकि Git वास्तव में index के साथ काम करता है, जब हम नए कमिट करते हैं, तो हम सावधानीपूर्वक चालबाजी के साथ, ऐसे रिपॉजिटरी के साथ काम कर सकते हैं। यह मजेदार नहीं है, और बेहतर टूलिंग शायद अच्छा होगा, लेकिन यह दिखाता है कि आप कुछ समस्याओं को कैसे दूर कर सकते हैं।

ध्यान दें कि जब आपने core.ignorecase को बंद कर दिया है, तो फ़ाइल नाम केस को ठीक करने के लिए आप जिम्मेदार हैं। Git सोचेगा—गलत तरीके से—कि dir/file बनाने से dir/file बन जाएगा, भले ही Dir/ नाम का फोल्डर मौजूद हो। आपको मैन्युअल रूप से rm -r संपूर्ण Dir निर्देशिका को बदलना होगा, या इसका नाम बदलना होगा:

mv Dir save
git checkout -- dir/file

उदाहरण के लिए—ताकि जब गिट dir बनाने के लिए जाता है, तो OS इसके बजाय मौजूदा Dir/ निर्देशिका का उपयोग नहीं करता है।

यह निश्चित रूप से एक अच्छा विचार है कि core.ignorecase को वापस चालू करें (यह मानते हुए कि यह प्रारंभ में चालू था: git config --get का पता लगाने के लिए उपयोग करें) एक बार जब आप इस प्रकार के मैनुअल, सावधान, एक-फ़ाइल-पर- एक समय खुदाई-के बारे में।

ध्यान दें कि:

git checkout <commit> -- <path>

Git को दिए गए <path> को कुछ विशिष्ट कमिट से निकालने के लिए कहता है:

  1. इसे गिट की अनुक्रमणिका में कॉपी करना: core.ignorecase बंद के साथ, गिट सोचता है कि एक अलग मामले के साथ कुछ समान नाम रखना ठीक है;
  2. परिणामी अनुक्रमणिका फ़ाइल को अपने कार्य-वृक्ष पर कॉपी करना; यह वह जगह है जहां आप पर यह सुनिश्चित करने की जिम्मेदारी है कि किसी भी मौजूदा फ़ोल्डर में सही मामला है।

यह वही है जो मेरा मतलब "टुकड़े-टुकड़े" से था, जिस तरह से लंबे खंड के शीर्ष पर। फार्म:

git checkout -- <path>

Git को Git की अनुक्रमणिका में वर्तमान सामग्री से दिए गए पथ को निकालने के लिए कहता है।

तथ्य यह है कि हम एक मामले में प्रतिबद्ध विनिर्देशक का उपयोग करते हैं, और इसे दूसरे में छोड़ देते हैं, भ्रमित है। यदि आपके पास Git 2.23 या बाद का संस्करण है, तो आप git checkout के बजाय git restore का उपयोग कर सकते हैं। restore कमांड आपको कुछ सामग्री के स्रोत को कमिट या इंडेक्स के रूप में निर्दिष्ट करने देता है। यदि आप कोई कमिट चुनते हैं, तो आप निर्दिष्ट कर सकते हैं कि फ़ाइल को से इंडेक्स में कॉपी किया जाना है, या आपके वर्क-ट्री, या दोनों को। यदि आप अनुक्रमणिका को स्रोत के रूप में चुनते हैं, तो फ़ाइल को से कॉपी करने का एकमात्र स्थान आपका कार्य-वृक्ष है।

(आखिरी इस तथ्य से अनुसरण करता है कि आपके कार्य-पेड़ और गिट की अनुक्रमणिका दोनों को लिखा जा सकता है, लेकिन एक प्रतिबद्धता केवल पढ़ी जा सकती है।)

1
torek 8 जिंदा 2021, 23:30