मैं गिट में अस्थिर परिवर्तनों से "पुरानी मोड 100755 नई मोड 100644" कह रही फ़ाइलों को कैसे हटाऊं?

Question

किसी कारण से, जब मैंने शुरू में मेरे एक गिट प्रोजेक्ट के लिए रिपॉजिटरी से एक पुल किया, तो मुझे अपनी वर्किंग कॉपी में एक टन फाइलें मिलीं जिनमें उनके लिए कोई परिवर्तन नहीं किया गया, लेकिन अपने unstaged changesक्षेत्र में दिखाई देते रहे।

मैं विंडोज xp पर Git Gui का उपयोग कर रहा हूं, और जब मैं फाइल को देखने के लिए देखने जाता हूं कि क्या बदल गया है। सभी मैं देख रहा हूँ:

old mode 100755  
new mode 100644  

क्या किसी को पता है कि इसका क्या मतलब है?

मैं इन फ़ाइलों को अस्थिर परिवर्तनों की अपनी सूची से कैसे निकाल सकता हूं? (बहुत परेशान करने वाली बात यह है कि मुझे अभी हाल ही में संपादित की गई फाइलों को चुनना है और कमिट करना है)।

Answer 1

यह मुझे ( 755= rwxr-xr-x, 644= rw-r--r--) के लिए यूनिक्स फ़ाइल अनुमति मोड की तरह दिखता है - पुराने मोड में + x (निष्पादन योग्य) ध्वज शामिल था, नया मोड ऐसा नहीं करता है।

इस msysgit मुद्दे के उत्तरों से पता चलता है कि मुद्दे से छुटकारा पाने के लिए core.filemode को झूठा सेट करना है:

git config core.filemode false

Comments

+1। इसका मतलब यह है कि गिट सोचता है कि यह सही ढंग से जाँच की गई फ़ाइलों पर निष्पादन योग्य बिट सेट कर सकता है, लेकिन जब वह ऐसा करने का प्रयास करता है तो यह काम नहीं करता है (या कम से कम इस तरह से नहीं है कि वह पढ़ सके)। जब यह वापस उन फ़ाइलों की स्थिति को पढ़ता है तो ऐसा लगता है कि निष्पादन योग्य बिट जानबूझकर परेशान हो गया है। Core.filemode को गलत पर सेट करना फ़ाइल सिस्टम पर किसी भी निष्पादन योग्य बिट परिवर्तनों को अनदेखा करने के लिए गिट को बताता है, इसलिए यह इसे परिवर्तन के रूप में नहीं देखेगा। यदि आपको एक निष्पादन योग्य परिवर्तन करने की आवश्यकता है, तो इसका मतलब है कि आपको मैन्युअल रूप से करना होगा git update-index --chmod=(+|-)x <path>।

— सीबी बेली

अगर, मेरी तरह, मोड परिवर्तन महत्वपूर्ण हैं, तो आप core.filemode को गलत पर सेट कर सकते हैं, अपने वास्तविक कोड परिवर्तन कर सकते हैं, और फिर core.filemode को सही पर सेट कर सकते हैं और फ़ाइल परिवर्तन को संरक्षित कर सकते हैं।

— माइकल टी। स्मिथ

मैं एक ही समस्या है, लेकिन यह SSH git cmd लाइन के माध्यम से समान git repro का उपयोग करने के कारण था, और Windows में मैप्ड ड्राइव पर Git एक्सटेंशन के माध्यम से! । । समाधान वही था, जिसे "कॉन्फिगर" में जोड़ा गया था [कोर] फिलमोड = असत्य

— इयान वॉन

यह एक जीवन रक्षक था, धन्यवाद सर! यह मेरे लिए OSX पर हुआ, जब मैंने सार्वजनिक फ़ोल्डर पर एक क्लोन रिपॉजिटरी साझा की और फ़ाइलों के लिए अनुमतियाँ बदल दीं।

— थियागो गानजारोलि

@robsch आप git config --global ...अपनी वैश्विक कॉन्फिग फ़ाइल में विकल्प सेट करने के लिए उपयोग कर सकते हैं ।

— अंबर

Answer 2

core.filemodeझूठी सेटिंग पर काम होता है, लेकिन सुनिश्चित करें कि सेटिंग्स ~/.gitconfigउन लोगों द्वारा ओवरराइड नहीं की जा रही हैं .git/config।

Comments

वहाँ किया गया था कि। दुख की बात है कि मुझे आपकी समस्या का समाधान करने के बाद ही आपकी टिप्पणी मिली। फिर भी, +1!

— डेविड श्मिट

यदि अन्य उपयोगकर्ता इस प्रोजेक्ट को क्लोन कर रहे हैं, तो यह विंडोज पर है, यह वास्तव में सबसे अच्छा हो सकता है कि केवल ~/.gitconfigफाइल में बदलाव लागू करें !

— इयान वघन

अगर आप Windows Powershell पर check करना चाहते हैं। git config --list --show-origin | sls filemodeया लिनक्स पर git config --list --show-origin | grep filemode। यह आपको दिखाएगा कि आपको समायोजन करने की आवश्यकता कहां है।

— फ्रैंक फू

आप इसे किसी न किसी!! बहुत बढ़िया।

— किम

Answer 3

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

sudo chmod -R -x . # remove the executable bit from all files

पूर्व कमांड वास्तव में उन अंतरों को हल करेगा जो गिट भिन्न रिपोर्ट किए गए हैं, लेकिन निर्देशिकाओं को सूचीबद्ध करने की आपकी क्षमता को रद्द कर देंगे, इसलिए इसके ls ./साथ विफल हो जाता है ls: .: Permission denied। इसे ठीक करने के लिए:

sudo chmod -R +X . # add the executable bit only for directories

बुरी खबर यह है कि यदि आपके पास कोई भी फाइल है जिसे आप निष्पादन योग्य रखना चाहते हैं, जैसे .shस्क्रिप्ट, तो आपको उन लोगों को वापस करना होगा। आप प्रत्येक फ़ाइल के लिए निम्न आदेश के साथ कर सकते हैं:

chmod +x ./build.sh # where build.sh is the file you want to make executable again

Comments

धन्यवाद, मेरी बहुत मदद की! किसी को यह भी जांचना चाहिए कि git config core.filemodeक्या सेट है true, अन्यथा अनुमति परिवर्तन का पता नहीं लगाया जाएगा। मुझे इसे लेने के लिए हर बदलाव के बाद git इंडेक्स को रिफ्रेश करने की भी जरूरत थी।

— pat-s

यदि आप प्रभावित निर्भरताओं से चिंतित हैं तो यह समाधान सबसे सुरक्षित है।

— जिन

Answer 4

आमतौर पर तब होता है जब रेपो को विंडोज और लिनक्स / यूनिक्स मशीनों के बीच क्लोन किया जाता है।

जिट को फिल्माएड परिवर्तन को अनदेखा करने के लिए कहें, यहाँ कई तरीके हैं:

1. केवल वर्तमान रेपो के लिए कॉन्फ़िगर करें:

   git config core.filemode false
   

2. विश्व स्तर पर कॉन्फ़िगर करें:

   git config --global core.filemode false
   

3. ~ / .Gitconfig में जोड़ें:

   [core]
        filemode = false
   

बस उनमें से एक का चयन करें।

Comments

वैश्विक कॉन्फ़िगरेशन काम नहीं करता क्योंकि (मुझे लगता है) git इस विकल्प के साथ एक रेपो बनाता है जो सही पर सेट है (मैंने linux में एक रेपो बनाया है)

— Herrgott

Answer 5

ऐसा लगता है कि आपने निर्देशिका की कुछ अनुमतियां बदल दी हैं। इसे पुनर्स्थापित करने के लिए मैंने निम्नलिखित कदम उठाए।

$  git diff > backup-diff.txt                ### in case you have some other code changes 

$  git checkout .

Answer 6

आप अपेक्षित डिफ़ॉल्ट स्थिति में रेपो को रीसेट करने के लिए जीआईटी रीसेट - भार हेड का प्रयास कर सकते हैं।

Comments

यदि पुल के बाद git निष्पादन योग्य बिट को सही ढंग से / लगातार सेट करने में सक्षम नहीं था, तो रीसेट के बाद यह किसी भी बेहतर तरीके से उचित नहीं होगा।

— सीबी बेली

मैंने कुछ प्रोजेक्ट्स को एक usb ड्राइव (fat32) में स्थानांतरित किया और अपनी ubuntu मशीन (ext4) पर वापस लाया और परिवर्तित फ़ाइलों का एक गुच्छा, अच्छी तरह से, विशेषताओं के साथ समाप्त हुआ। git reset --hard HEADमेरे लिए पूरी तरह से काम किया। धन्यवाद

— cirovladimir

-1। ओपी ने कहा "अभी हाल ही में संपादित की गई फ़ाइलों को निकालना चाहता हूं और कमिट करना चाहता हूं"। यह उन संपादन को भी हटा देगा।

— वाइटफिन

-1 इस कमांड को git में सुझाना "आप बस rm -rf ./ कहने के समान है, मुझे यकीन है कि इसका कोई अनपेक्षित परिणाम नहीं होगा"।

— क्ज़िकई

नहीं, यह मदद नहीं करता है और यह समस्या है। आप रीसेट और साफ और अभी भी गिट स्थिति स्थिति परिवर्तन दिखा रहा है। यह विंडोज़ गिट के साथ एक गंभीर समस्या है और मुझे लगता है कि इसे ठीक किया जाना चाहिए, न कि फ़ाइल मोड को अनदेखा करके चारों ओर काम किया जाए।

— वेजेनकोव

Answer 7

मैंने उसी मुद्दे का सामना किया है। और इससे मेरी जान बचती है: https://gist.github.com/jtdp/5443498

git diff -p -R --no-color \
| grep -E "^(diff|(old|new) mode)" --color=never  \
| git apply`

Answer 8

ऐसा तब होता है जब आप खींचते हैं और दूरस्थ रिपॉजिटरी में सभी फाइलें निष्पादन योग्य थीं। उन्हें फिर से निष्पादन योग्य बनाने से सब कुछ फिर से सामान्य हो जाएगा।

chmod +x <yourfile> //For one file
chmod +x folder/* // For files in a folder

आपको करने की आवश्यकता हो सकती है:

chmod -x <file> // Removes execute bit

इसके बजाय, उन फ़ाइलों के लिए जिन्हें निष्पादन योग्य के रूप में सेट नहीं किया गया था और जिन्हें उपरोक्त ऑपरेशन के कारण बदल दिया गया था। ऐसा करने का एक बेहतर तरीका है, लेकिन यह सिर्फ एक बहुत ही त्वरित और गंदा फिक्स है।

Answer 9

आप अपने फ़ाइल मोड को वापस बदलने के लिए निम्न कमांड का उपयोग कर सकते हैं। git add --chmod=+x -- filename फिर शाखा के लिए प्रतिबद्ध।

Answer 10

मेरे पास बदली हुई अनुमतियों के साथ सिर्फ एक परेशानी वाली फ़ाइल थी। इसे व्यक्तिगत रूप से वापस करने के लिए, मैंने इसे मैन्युअल रूप से हटा दिया rm <file>और फिर एक ताज़ा प्रतिलिपि खींचने के लिए एक चेकआउट किया।

सौभाग्य से मैंने अभी तक इसका मंचन नहीं किया था।

अगर मेरे पास होता तो मैं दौड़ने git reset -- <file>से पहले दौड़ सकता थाgit checkout -- <file>

Answer 11

जब मैं अपनी शाखा को मास्टर के साथ अलग करता हूं तो मैं सिर्फ इस मुद्दे पर भागता हूं। जब मैंने अपनी शाखा को मास्टर के समान होने की उम्मीद की तो Git ने एक 'मोड' त्रुटि लौटा दी। मैंने फ़ाइल को हटाकर और फिर मास्टर को फिर से मर्ज करने का निर्णय लिया।

पहले मैंने फ़ॉर रन चलाया:

git checkout my-branch
git diff master

यह लौटा:

diff --git a/bin/script.sh b/bin/script.sh
old mode 100755
new mode 100644

मैं तो ठीक करने के लिए निम्नलिखित भाग गया:

rm bin/script.sh
git merge -X theirs master

इसके बाद, git diffमेरी शाखा और गुरु के बीच कोई अंतर नहीं लौटा।