मुझे Git में core.autocrlf = true का उपयोग क्यों करना चाहिए?

Question

मेरे पास एक Git रिपॉजिटरी है जो Windows और OS X दोनों से एक्सेस की गई है, और मुझे पता है कि इसमें CRLF लाइन-एंडिंग वाली कुछ फाइलें पहले से हैं। जहां तक ​​मैं बता सकता हूं, इससे निपटने के दो तरीके हैं:

1. सेट core.autocrlfकरने के लिए falseहर जगह,

2. यहां निर्देशों का पालन करें (केवल GFHub की मदद पृष्ठों पर गूँजती है) केवल LF लाइन-एंडिंग्स को रिपॉजिटरी में बदलने के लिए, और उसके बाद विंडोज और OS X पर सेट core.autocrlfकरें । ऐसा करने के साथ समस्या यह है कि अगर मैं रिपॉजिटरी में कोई भी बाइनरी फाइल करता हूं उस:trueinput

   1. gitattributes में बाइनरी के रूप में सही ढंग से चिह्नित नहीं हैं, और
   2. CRLFs और LFs दोनों को शामिल करने के लिए,

   वे भ्रष्ट हो जाएंगे। यह संभव है कि मेरे भंडार में ऐसी फाइलें हों।

तो मुझे Git के लाइन-एंड रूपांतरण को बंद क्यों नहीं करना चाहिए? वेब पर बहुत सारी अस्पष्ट चेतावनियाँ हैं core.autocrlf, जो समस्याओं का कारण बन रही हैं, लेकिन बहुत कम विशिष्ट हैं; केवल इतना है कि मैंने पाया है कि kdiff3 CRLF एंडिंग (मेरे लिए कोई समस्या नहीं) को संभाल नहीं सकता है, और कुछ पाठ संपादकों के पास लाइन-एंडिंग मुद्दे (मेरे लिए भी कोई समस्या नहीं है)।

रिपॉजिटरी मेरी कंपनी के लिए आंतरिक है, और इसलिए मुझे इसे अलग-अलग ऑटोक्रॉफ्ट सेटिंग्स या लाइन-एंडिंग आवश्यकताओं वाले लोगों के साथ साझा करने के बारे में चिंता करने की आवश्यकता नहीं है।

क्या लाइन-एंडिंग को छोड़ने के साथ कोई अन्य समस्याएं हैं जैसे कि मैं अनजान हूं?

Comments

क्या stackoverflow.com/questions/2333424/… मदद करेगा? मेरे पास autocrlfझूठे को छोड़ने के विशिष्ट कारणों के लिए लिंक है ।

— VonC

@VonC धन्यवाद, लेकिन मैं पहले से ही यह तय करने में सक्षम हूं कि कंपनी के सभी उपयोगकर्ता झूठ बोलने के लिए <code> autocrlf </ code> सेट करते हैं और वर्तमान में मानते हैं कि सबसे अच्छा विकल्प है। लेकिन मैं जानना चाहता हूं कि क्या कोई कारण है कि मुझे ऐसा क्यों नहीं करना चाहिए , क्योंकि मुझे पता चल सकता है कि बहुत सारे लोग (जैसे गिटहब) हैं जो कहते हैं कि मुझे आटोक्रॉफ़ल सेट करना चाहिए लेकिन कोई वास्तविक विवरण क्यों नहीं।

— रिच

@VonC यानी मैं autocrlfअसत्य पर सेट होने के कारणों की तलाश नहीं कर रहा हूं । मैं इसे सच करने के लिए कारणों की तलाश कर रहा हूं।

— रिच

क्यों नहीं उपयोग करें autocrlf = input: यह दो चरम सीमाओं के बीच सही समाधान प्रतीत होता है: आप अपने रेपो को CRLF बकवास से साफ रखते हैं, और स्थानीय रूप से विंडोज डेवलपर अपनी स्थानीय फ़ाइलों के बिना जो कुछ भी चाहते हैं उसका उपयोग कर सकते हैं, जो उनके लिए स्वचालित रूप से कुछ भी जादू नहीं करता है। (वे विभिन्न कारणों से स्थानीय स्तर पर LF चाहते हैं, इसलिए trueमेरी राय में यह बुरा है।) मैं उपयोग करने के लिए कोई डाउनसाइड नहीं देख सकता autocrlf = input।

— iconoclast

@iconclast, मेरे द्वारा चलाए जाने का एक कारण यह है कि यदि आप ऐसे वितरण का निर्माण करते हैं जिसमें विंडोज बैच की फाइलें और यूनिक्स शैल स्क्रिप्ट शामिल हैं। आप प्रत्येक मामले में समाप्त होने वाली सही लाइन का उपयोग करना चाहते हैं, और यह कठिन है कि यदि गिट स्पष्ट रूप से एक या दूसरे तरीके से सेट करने के बाद भी आपके आस-पास चीजों को घुमा रहा है।

— user1809090

Answer 1

सेट autocrlfकरने के लिए केवल विशिष्ट कारण trueहैं:

• जब एक यूनिक्स-आधारित ईओएल गिट रेपो का क्लोनिंग एक विंडोज एक के लिए किया जाता है, तो स्वचालित ईओएल रूपांतरण के कारण git statusअपनी सभी फाइलों को दिखाने से बचें modified( उदाहरण के लिए मुद्दा 83 देखें )
• और आपके कोडिंग उपकरण किसी तरह आपकी फाइल में मौजूद एक देशी ईओएल शैली पर निर्भर करते हैं:
  • उदाहरण के लिए, एक कोड जनरेटर हार्ड कोडित देशी ईओएल का पता लगाने के लिए
  • देशी ईओएल का पता लगाने के लिए regexp या कोड सेट के साथ अन्य बाहरी बैच (आपके रेपो के लिए बाहरी)
  • मेरा मानना ​​है कि कुछ ग्रहण प्लगइन्स CRLF के साथ प्लेटफ़ॉर्म पर परवाह किए बिना फ़ाइलों का उत्पादन कर सकते हैं, जो एक समस्या हो सकती है।
  • आप Notepad.exe के साथ कोड करते हैं ( जब तक कि आप विंडोज 10 2018.09+ का उपयोग नहीं कर रहे हैं, जहां Notepad EOL वर्ण का पता लगाता है )।

जब तक आप विशिष्ट उपचार नहीं देख सकते हैं जो देशी ईओएल से निपटना चाहिए , आप ( ) को छोड़ने autocrlfसेfalse बेहतर हैं git config --global core.autocrlf false।

ध्यान दें कि यह विन्यास एक स्थानीय होगा (क्योंकि विन्यास को रेपो से रेपो में नहीं धकेला जाता है)

आप सभी उपयोगकर्ताओं है कि रेपो क्लोनिंग के लिए एक ही config चाहते हैं, बाहर की जाँच " सबसे अच्छा है क्या CRLFGit के साथ निपटने की रणनीति? का उपयोग कर", textमें विशेषता .gitattributesफ़ाइल ।

उदाहरण:

*.vcproj    text eol=crlf
*.sh        text eol=lf

---

नोट: git 2.8 (मार्च 2016) को शुरू करते हुए, मर्ज मार्कर अब CRLF फ़ाइल में मिश्रित लाइन एंडिंग (LF) का परिचय नहीं देंगे ।
" Git का उपयोग करें CRLF को उसके" <<<<<<<< HEAD "मर्ज लाइनों " पर देखें

Comments

@VonC धन्यवाद! यह मुझे और अधिक आत्मविश्वास महसूस करने में मदद करता है कि यह मेरे लिए उपयोग करने के लिए सुरक्षित है autocrlf=false। रुचि से, क्या आप जानते हैं कि अगर आप के पास असत्य सेट करने के लिए झूठे हैं तो भी gol अभी भी eol रूपांतरण क्यों करता है?

— रिच

@VonC: मुझे नहीं लगता कि यह उत्तर सही है। Windows पर core.autocrlf = true का उपयोग करना अपेक्षित है। रेपो से सभी फाइलें (जिसमें इस परिदृश्य में LF लाइन एंडिंग होनी चाहिए) CRLF लाइन एंडिंग्स से विंडोज पीसी पर चेकआउट में बदल जाती हैं। सभी फाइलें एक विंडोज पीसी की ओर से वापस एलएफ लाइन एंडिंग में बदल जाती हैं। मुसीबत में आने का तरीका गलत कोर.ऑटोक्रॉफ्ट सेटिंग (जो पूरी तरह से करना बहुत आसान है) के साथ शुरुआत में विंडोज पीसी पर चेकआउट करना है।

— माइकल मैडॉक्स

@ मिचेल तो उस स्थिति core.autocrlf=falseमें मेरे परिदृश्य में उपयोग न करने का एकमात्र कारण यह है कि क्या मेरे पास कुछ उपकरण / संपादक थे जो लाइन-एंडिंग से भ्रमित हो जाते?

— रिच

मैं निश्चित रूप से उपयोग करूंगा false, मैं कभी भी पृष्ठभूमि में होने वाली स्वचालित या जादूई चीजों का बड़ा प्रशंसक नहीं रहा हूं। बस का उपयोग करें \nऔर UTF-8हर जगह और आप ठीक हो जाएगा। यदि कुछ अखरोट-सिर यह नहीं समझते हैं कि सम्मेलन और नियम हैं और उपयोग करने के लिए भूल जाते हैं UTF-8या \n, तो कोई उन्हें मैन्युअल रूप से परिवर्तित करता है और उसके चेहरे को थप्पड़ मारता है।

— टॉवर

@ पाउल्डअवॉटर मैं अभी भी इस वैश्विक सेटिंग का उपयोग करने के बजाय core.eolएक .gitattributesफ़ाइल में विशेषताओं के माध्यम से उस फ़ाइल के प्रकार को निर्दिष्ट करना पसंद करूंगा , core.autocrlfजो सभी फाइलों पर अंधाधुंध लागू होता है ।

— VonC

Answer 2

मैं एक .NET डेवलपर हूं, और वर्षों तक Git और Visual Studio का उपयोग किया है। मेरी मजबूत सिफारिश सच करने के लिए लाइन अंत सेट है। और इसे अपने रिपॉजिटरी के जीवनकाल में जितना जल्दी हो सके उतना जल्दी करें।

यह कहा जा रहा है, मुझे नफरत है कि Git मेरी लाइन अंत को बदल देता है। एक स्रोत नियंत्रण को केवल मेरे द्वारा किए जाने वाले कार्य को सहेजना और पुनः प्राप्त करना चाहिए, इसे संशोधित नहीं करना चाहिए। कभी। लेकिन यह करता है।

क्या होगा यदि आपके पास हर डेवलपर सेट करने के लिए सही नहीं है, क्या एक डेवलपर अंततः सच में सेट हो जाएगा। यह आपकी सभी फ़ाइलों की लाइन अंत को आपके रेपो में LF में बदलना शुरू कर देगा। और जब उपयोगकर्ता उन लोगों की झूठी जाँच करने के लिए सेट करते हैं, तो Visual Studio आपको चेतावनी देगा, और आपको उन्हें बदलने के लिए कहेगा। आपके पास 2 चीजें बहुत जल्दी होंगी। एक, आप उन चेतावनियों को अधिक से अधिक प्राप्त करेंगे, जितनी बड़ी आपकी टीम उतनी ही अधिक। दूसरी, और इससे भी बुरी बात यह है कि यह दिखाएगा कि हर संशोधित फाइल की हर लाइन को बदल दिया गया था (क्योंकि हर लाइन का लाइन एंडिंग सच्चे आदमी द्वारा बदल दिया जाएगा)। आखिरकार आप अब और मज़बूती से अपने रेपो में परिवर्तनों को ट्रैक नहीं कर पाएंगे। हर किसी को झूठे रखने की कोशिश करने की तुलना में, हर किसी को सही रखने के लिए यह आसान और साफ है। के रूप में भयानक के रूप में यह इस तथ्य के साथ रहना है कि आपके विश्वसनीय स्रोत नियंत्रण कुछ ऐसा कर रहा है जो इसे नहीं करना चाहिए। कभी।

Comments

मेरी कंपनी इतनी छोटी है कि हम आसानी से उस झूठ का इस्तेमाल कर सकते हैं, जिसका इस्तेमाल हर जगह किया जाता है, और मैंने सोचा होगा कि बड़ी कंपनियां पॉलिसी के जरिए ऐसा कर सकती हैं, लेकिन मुझे लगता है कि यह "सही" इस्तेमाल करने का एक वैध कारण है, इसलिए मैं अपवित्र हो रही हूं वैसे भी। धन्यवाद!

— रिच

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

— JGTaylor

बिल्कुल वही जो मैं सोचता हूं। यह कोड फ़ाइलों के साथ गड़बड़ करने के लिए स्रोत नियंत्रण का काम नहीं करता है क्योंकि यह प्रसन्न होता है। लाइन एंडिंग केवल एडिटिंग टूल्स की चिंता होनी चाहिए, इससे ज्यादा कुछ नहीं।

— टुन्के गोन्कोउलू

यदि आपका प्रोजेक्ट विंडोज-ही है तो कोई समस्या नहीं है। हालाँकि यदि आप या आपके सहकर्मी * निक्स प्लेटफॉर्म पर काम करते हैं तो आपकी "मजबूत सिफारिश" समस्या पैदा करेगी। शेबांग के साथ एक बैश, पर्ल या पाइथन स्क्रिप्ट चलाने की कोशिश करें \r\nऔर आप देखेंगे।

— फुल्विक

आपके द्वारा वर्णित स्थिति जीआईटी की समस्या नहीं है, सेटिंग को FALSE पर सेट करें क्योंकि यह आमतौर पर होना चाहिए और यह चला गया है। Instad, यह टीम के काम में एक समस्या है। इसका क्या अर्थ है "अंततः एक डेवलपर सेट true"? आप उन्हें पहली जगह देने की अनुमति क्यों देंगे? जब आप उन्हें git repo तक पहुँचने के लिए सेट करते हैं, तो जैसे आप अलग-अलग लैंग के साथ कुछ क्षेत्रों को प्रदूषित करने की अनुमति नहीं देते हैं (इसलिए कोई भी उस पर काम कर रहा है) उसे पढ़ सकते हैं, या जैसे आप शाखाओं / मर्ज / विद्रोह / आदि को चुने हुए साथ रखते हैं। नीति, उन्हें एक स्पष्ट नियम प्राप्त करना चाहिए: सही क्रैम्प सेट करें।

— quetzalcoatl

Answer 3

अपडेट 2 :

Xcode 9 में एक "सुविधा" दिखाई देती है, जहाँ यह फ़ाइल की वर्तमान पंक्ति के अंत को अनदेखा कर देगी, और इसके बजाय बस एक फ़ाइल में लाइनें सम्मिलित करते समय अपनी डिफ़ॉल्ट पंक्ति-समाप्ति सेटिंग का उपयोग करें, जिसके परिणामस्वरूप मिश्रित लाइन अंत वाली फ़ाइलें होती हैं।

मुझे पूरा यकीन है कि यह बग Xcode 7 में मौजूद नहीं था; Xcode 8 के बारे में निश्चित नहीं है। अच्छी खबर यह है कि यह Xcode 10 में तय किया गया प्रतीत होता है।

जिस समय तक यह अस्तित्व में था, इस बग ने कोडबेस में थोड़ी मात्रा में उल्लसितता पैदा कर दी, जिसका मैं प्रश्न में उल्लेख करता हूं (जो आज तक उपयोग करता है autocrlf=false), और कई "ईओएल" संदेशों को अंजाम दिया और अंततः मेरे लेखन pre-commitकी जाँच करने के लिए एक गिट हुक का उपयोग किया। मिश्रित लाइन एंडिंग शुरू करने / रोकने के लिए।

अपडेट :

नोट: जैसा कि VonC द्वारा नोट किया गया है, Git 2.8 से शुरू होकर, मर्ज मार्कर विंडोज-स्टाइल फाइल में यूनिक्स-स्टाइल लाइन-एंडिंग को पेश नहीं करेंगे ।

मूल :

एक छोटे से हिचकी है कि मैं इस सेटअप के साथ देखा है कि जब वहाँ मर्ज संघर्ष, लाइनों Git मतभेद को चिह्नित करने के है कहते हैं न आप अंत कर सकते हैं विंडोज लाइन अंत है, तब भी जब फ़ाइल के बाकी है, और मिश्रित लाइन एंडिंग वाली फ़ाइल के साथ, जैसे:

// Some code<CR><LF>
<<<<<<< Updated upstream<LF>
// Change A<CR><LF>
=======<LF>
// Change B<CR><LF>
>>>>>>> Stashed changes<LF>
// More code<CR><LF>

यह हमें किसी भी समस्या का कारण नहीं बनता है (मैं किसी भी उपकरण की कल्पना करता हूं जो दोनों प्रकार के लाइन-एंडिंग को संभाल सकता है, मिश्रित लाइन-एंडिंग के साथ भी समझदारी से निपटेगा - निश्चित रूप से सभी जो हम उपयोग करते हैं), लेकिन इसके बारे में पता होना चाहिए।

दूसरी चीज ^* हमने पाया है, यह है कि जब git diffविंडोज लाइन-एंडिंग वाली फाइल में परिवर्तन देखने के लिए उपयोग किया जाता है, तो जो लाइनें जोड़ी गई हैं, वे अपने कैरिज रिटर्न को प्रदर्शित करती हैं, इस प्रकार:

    // Not changed

+   // New line added in^M
+^M
    // Not changed
    // Not changed

_{* यह वास्तव में शब्द का गुण नहीं देता है: "मुद्दा"।}

Comments

NB जब विज़ुअल स्टूडियो इस तरह की फ़ाइल का सामना करता है, तो यह आपके लिए लाइन-एंडिंग को सामान्य करने की पेशकश करता है। विंडोज लाइन-एंडिंग को चुनना या लाइन-एंडिंग को सामान्य नहीं करने के लिए चुनाव करना ठीक काम करता है (क्योंकि वीएस अभी भी इसे सही ढंग से प्रदर्शित करता है कि एक बार संघर्ष को हल करने के बाद आक्रामक लाइनों को हटा दिया जाएगा)।

— रिच

दुर्भाग्य से कॉरपोरेट संस्करण नियंत्रण नाज़ियों से असहमत है (एलएफ ऑन मर्ज संघर्ष मार्कर) एक मुद्दा नहीं है।

— इलिया जी

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

— लूट

ध्यान दें: git 2.8 (मार्च 2016) शुरू होने पर, मर्ज मार्करों में वास्तव में CRLF लाइन समाप्त हो जाएगी। देखें stackoverflow.com/a/35474954/6309

— VONC