विभिन्न ऑपरेटिंग सिस्टम के बीच git core.autocrlf के साथ रूपांतरण समाप्त करने वाली लाइन कैसे काम करती है

Question

मैं स्टैक ओवरफ़्लो के साथ ही अलग-अलग सवाल और जवाब का एक बहुत पढ़ा है Git कैसे पर प्रलेखन core.autocrlf सेटिंग काम करता है।

यह मेरी समझ है कि मैंने क्या पढ़ा है:

यूनिक्स और मैक ओएसएक्स (प्री-ओएसएक्स सीआर का उपयोग करता है) क्लाइंट एलएफ लाइन एंडिंग का उपयोग करते हैं।
विंडोज क्लाइंट CRLF लाइन एंडिंग्स का उपयोग करते हैं।

जब core.autocrlf क्लाइंट पर सच में सेट हो जाता है, तो git रिपॉजिटरी हमेशा LF लाइन एंडिंग फॉर्मेट में फाइल्स को स्टोर करती है और क्लाइंट पर मौजूद फाइल्स में लाइन एंडिंग्स को चेक आउट / क्लाइंट्स के लिए कमिट (यानी विंडोज) में कन्वर्ट कर दिया जाता है जो नॉन का इस्तेमाल करते हैं -LF लाइन एंडिंग, कोई फर्क नहीं पड़ता कि क्या लाइन एंडिंग फाइल क्लाइंट पर हैं (यह टिम क्लेम की परिभाषा से असहमत है - नीचे अपडेट देखें)।

यहां एक मैट्रिक्स है जो प्रश्नवाचक चिन्ह के साथ core.autocrlf की 'इनपुट' और 'झूठी' सेटिंग्स के लिए समान दस्तावेज़ बनाने की कोशिश करता है जहां मैं लाइन अंत रूपांतरण व्यवहार के बारे में सुनिश्चित नहीं हूं।

मेरे प्रश्न हैं:

1. प्रश्नवाचक चिन्ह क्या होना चाहिए?
2. क्या यह मैट्रिक्स "गैर-प्रश्न चिह्न" के लिए सही है?

मैं उत्तरों से सवालिया निशान अपडेट करता हूँ क्योंकि आम सहमति बनती है।

                       core.autocrlf value
            सच्चा इनपुट झूठा
-------------------------------------------------- --------
कमिट | परिवर्तित करें? ?
नया | LF (LF में कनवर्ट करें?) (कोई रूपांतरण नहीं?)

कमिट | में बदलें ? नहीं
मौजूदा | LF (LF में कनवर्ट करें?) रूपांतरण

चेकआउट | में बदलें ? नहीं
मौजूदा | CRLF (कोई रूपांतरण नहीं?) रूपांतरण

मैं वास्तव में विभिन्न सेटिंग्स के पेशेवरों और विपक्षों के बारे में राय नहीं ढूंढ रहा हूं। मैं सिर्फ डेटा की तलाश कर रहा हूं, जो यह स्पष्ट करता है कि तीन सेटिंग्स में से प्रत्येक के साथ काम करने की अपेक्षा कैसे की जाए।

-

अद्यतन ०४ /१ //२०११ : टिप्पणियों में जेजेडी द्वारा जुड़े टिम क्लेम के लेख को पढ़ने के बाद , मैंने ऊपर दी गई तालिका में "अज्ञात" मूल्यों में से कुछ मूल्यों को संशोधित किया है, साथ ही "चेकआउट मौजूदा" को बदलने के लिए सही है। ग्राहक को बदलने के बजाय CRLF में "। यहां वह परिभाषाएं हैं जो वह देता है, जो कि मैंने कहीं और देखा है, उससे अधिक स्पष्ट हैं:

core.autocrlf = false

यह डिफ़ॉल्ट है, लेकिन ज्यादातर लोगों को इसे तुरंत बदलने के लिए प्रोत्साहित किया जाता है। असत्य का उपयोग करने का परिणाम यह है कि Git आपकी फ़ाइल पर लाइन अंत के साथ कभी भी गड़बड़ नहीं करता है। आप LF या CRLF या CR या उन तीनों के कुछ यादृच्छिक मिश्रण के साथ फाइलों में जांच कर सकते हैं और Git परवाह नहीं करता है। यह पढ़ने के लिए और अधिक कठिन विलय को कठिन बना सकता है। यूनिक्स / लिनक्स की दुनिया में काम करने वाले ज्यादातर लोग इस मूल्य का उपयोग करते हैं क्योंकि उन्हें CRLF की समस्या नहीं है और जब भी फाइलें ऑब्जेक्ट डेटाबेस में लिखी जाती हैं या वर्किंग डायरेक्टरी में लिखी जाती हैं तो उन्हें अतिरिक्त काम करने की आवश्यकता नहीं होती है।

core.autocrlf = true

इसका मतलब यह है कि Git सभी पाठ फ़ाइलों को संसाधित करेगा और सुनिश्चित करेगा कि CRLF को LF के साथ बदल दिया जाए जब वह फ़ाइल ऑब्जेक्ट डेटाबेस में लिखती है और सभी LF को वापस CRLF में बदल देती है जब वर्किंग डायरेक्टरी में लिखते हैं। यह विंडोज पर अनुशंसित सेटिंग है क्योंकि यह सुनिश्चित करता है कि आपकी कार्यशील निर्देशिका में CRLF को बनाए रखते हुए आपके रिपॉजिटरी का उपयोग अन्य प्लेटफार्मों पर किया जा सकता है।

core.autocrlf = इनपुट

इसका मतलब यह है कि Git सभी टेक्स्ट फाइलों को प्रोसेस करेगा और सुनिश्चित करेगा कि CRLF को LF के साथ उस फाइल को ऑब्जेक्ट डेटाबेस में लिखते समय प्रतिस्थापित किया जाए। हालांकि, यह रिवर्स नहीं होगा। जब आप ऑब्जेक्ट डेटाबेस से फ़ाइलों को वापस पढ़ते हैं और उन्हें कार्यशील निर्देशिका में लिखते हैं तो उनके पास अभी भी लाइन के अंत को निरूपित करने के लिए एलएफ होंगे। यह सेटिंग CRLF को रिपॉजिटरी में लिखे जाने से रोकने के लिए आमतौर पर यूनिक्स / लिनक्स / ओएस एक्स पर उपयोग की जाती है। यह विचार कि यदि आपने एक वेब ब्राउज़र से कोड चिपकाया और गलती से आपकी एक फाइल में CRLFs आ गए, तो Git सुनिश्चित करेगा कि जब वे ऑब्जेक्ट डेटाबेस में लिखे गए थे, तो उन्हें LF के साथ बदल दिया गया था।

टिम का लेख उत्कृष्ट है, केवल एक चीज जो मुझे याद आ रही है वह यह है कि वह मानती है कि वह रिपॉजिटरी एलएफ प्रारूप में है, जो जरूरी नहीं कि सच है, खासकर विंडोज केवल परियोजनाओं के लिए।

टिम के लेख की जेमलाने द्वारा अब तक की सबसे ज्यादा वोटिंग के जवाब की तुलना करना सही और इनपुट सेटिंग्स पर सही समझौता और झूठी सेटिंग पर असहमति दिखाता है।

Comments

autocrlfझूठी रखना इतना आसान लगता है;) stackoverflow.com/questions/2333424/…

— VONC

@VonC: मैंने वह पढ़ा है और मुझे लगता है कि मैं इसे समझता हूं, लेकिन मुझे पसंद करने के लिए जरूरी नहीं है। मैं git रिपॉजिटरी के साथ काम करता हूं जिसे मैं नियंत्रित नहीं करता कि मुझे किसी निश्चित तरीके से मूल्य निर्धारित करने की आवश्यकता है।

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

क्या यह अच्छा नहीं होगा अगर विंडोज को LF के लिए भी सामान्य कर दिया जाए? मैक CR (पूर्व v10) हुआ करता था लेकिन अब इसे LF के लिए सामान्य कर दिया गया है।

— ब्रेट रायन

मुझे टिमोथी क्लेम के महान लेख के लिए एक लिंक जोड़ने की आवश्यकता है - कृपया माइंड द एंड ऑफ योर लाइन के सभी पढ़ें ।

— JJD

परिदृश्य: मैं एक विभाजित लिनक्स / विंडोज डेवलपर हूं। मैं केवल पाठ संपादकों का उपयोग करता हूं जो दोनों प्रकार के लाइन एंडिंग (IE। विम, ग्रहण) को पहचान सकते हैं। मुझे केवल LF में समाप्त होने वाली फ़ाइलों के साथ काम करने की आवश्यकता है (चाहते हैं)। वर्तमान में मेरे वैश्विक git config में core.autocrlf = इनपुट सेट है। क्या मैं जाने के लिए अच्छा हूँ? क्या मेरा कभी टकराव होगा?

— क्रिस

Answer 1

विशेषता अनुभाग में gitattributes मैन पेज core.autocrlfपर कैसे काम करता है, इसका सबसे अच्छा विवरण दिया गया है।text

यह core.autocrlfवर्तमान में (या कम से कम v1.7.2 के बाद से जो मुझे पता है) से काम करना प्रतीत होता है:

• core.autocrlf = true
  1. पाठ फ़ाइलों को उन भंडार से चेक-आउट किया गया है जिनमें केवल LFअक्षर हैं CRLFजो आपके काम करने वाले पेड़ में सामान्यीकृत हैं ; CRLFरिपॉजिटरी में मौजूद फाइलों को छुआ नहीं जाएगा
  2. पाठ फ़ाइलें जिनमें केवल LFरिपॉजिटरी के पात्र हैं, जब वे रिपॉजिटरी में वापस करने के CRLFलिए सामान्यीकृत होते हैं LF। CRLFरिपॉजिटरी में मौजूद फाइलें अनछुई हो जाएंगी।
• core.autocrlf = input
  1. रिपॉजिटरी से चेक-आउट की गई टेक्स्ट फाइलें आपके काम करने वाले पेड़ में मूल ईओएल अक्षर रखेंगी।
  2. CRLFवर्णों के साथ अपने काम के पेड़ में पाठ फ़ाइलों को सामान्य किया जाता है LFजब भंडार में वापस भेजा जाता है।
• core.autocrlf = false
  1. core.eol अपने काम के पेड़ की पाठ फ़ाइलों में ईओएल पात्रों को निर्देशित करता है।
  2. core.eol = nativeडिफ़ॉल्ट रूप से, जिसका अर्थ है कि विंडोज ईओएल हैं CRLFऔर * निक्स ईओएल LFकाम कर रहे पेड़ों में हैं।
  3. रिपॉजिटरी gitattributesसेटिंग्स रिपॉजिटरी के लिए ईओएल चरित्र सामान्यीकरण को निर्धारित करती है (डिफ़ॉल्ट LFवर्णों का सामान्यीकरण है )।

मैंने अभी हाल ही में इस मुद्दे पर शोध किया है और मुझे यह भी पता चला है कि स्थिति बहुत जटिल है। core.eolसेटिंग निश्चित रूप से यह स्पष्ट करने में मदद करती है कि कैसे EOL वर्णों को नियंत्रित किया जाता है।

Comments

ऑटोक्रॉफ्ट के लिए = सत्य निम्नलिखित नहीं होना चाहिए? पाठ फ़ाइलें जिनमें केवल भंडार में CRLF EOL वर्ण हैं, CRLF से LF तक सामान्यीकृत होते हैं जब वे भंडार में वापस किए जाते हैं। रिपॉजिटरी में LF वाली फाइलें अछूती नहीं रहेंगी।

— पियोट्र लेवंडोव्स्की

मेरे लिए, भले ही आटोक्रॉफ्ट = गलत गिट ईओएल को सीआरएलएफ में परिवर्तित कर रहा हो। इस उत्तर को पढ़ने के बाद मैंने महसूस किया कि मेरी .itattribute फ़ाइल में टेक्स्ट = ऑटो सेट था जो परेशानी पैदा कर रहा था।

— irisis

के लिए core.autocrlf = false, अगर मैं एक की जरूरत नहीं है gitattributesफ़ाइल इसका मतलब यह है कि वहाँ कोई सामान्य हो जाएगा? या इसका मतलब यह है कि यह डिफ़ॉल्ट सामान्यीकरण का उपयोग करेगा?

— चिन

सेटिंग .gitattributesपर पूर्वता दर्ज नहीं करनी चाहिए core.autocrlf?

— क्वर्टी

Answer 2

मिश्रित-प्लेटफ़ॉर्म परियोजनाओं में ईओएल का मुद्दा लंबे समय से मेरे जीवन को दयनीय बना रहा है। समस्याएँ आमतौर पर तब होती हैं जब पहले से ही रेपो में अलग और मिश्रित ईओएल के साथ फाइलें होती हैं । इस का मतलब है कि:

1. रेपो में अलग-अलग ईओएल के साथ अलग-अलग फाइलें हो सकती हैं
2. रेपो में कुछ फ़ाइलों में मिश्रित EOL हो सकता है, उदाहरण के लिए CRLFऔर LFउसी फ़ाइल का संयोजन ।

यह कैसे होता है यहां मुद्दा नहीं है, लेकिन ऐसा होता है।

मैंने विभिन्न मोड और उनके संयोजन के लिए विंडोज पर कुछ रूपांतरण परीक्षण चलाए।
यहाँ मुझे क्या मिला, थोड़ा संशोधित तालिका में:

                 | परिणामी रूपांतरण जब | परिणामी रूपांतरण जब
                 | विभिन्न के साथ फाइल करना | रेपो से जाँच -
                 | EOLs INTO रेपो और | इसमें मिश्रित फ़ाइलों के साथ और
                 | core.autocrlf value: | core.autocrlf मान:           
-------------------------------------------------- ------------------------------
फ़ाइल | सच | इनपुट | झूठा | सच | इनपुट | असत्य
-------------------------------------------------- ------------------------------
विंडोज-सीआरएलएफ | CRLF -> LF | CRLF -> LF | as- है | as- है | as- है | जैसा है
यूनिक्स -LF | as- है | as- है | as- है | LF -> CRLF | as- है | जैसा है
मैक -सीआर | as- है | as- है | as- है | as- है | as- है | जैसा है
मिश्रित- CRLF + LF | as- है | as- है | as- है | as- है | as- है | जैसा है
मिश्रित- CRLF + LF + CR | as- है | as- है | as- है | as- है | as- है | जैसा है

जैसा कि आप देख सकते हैं, रूपांतरण होने पर 2 मामले होते हैं (3 बाएं कॉलम)। बाकी मामलों में फाइलें इस प्रकार प्रतिबद्ध हैं।

चेकआउट (3 सही कॉलम) होने पर, केवल 1 मामला होता है जहां रूपांतरण तब होता है:

1. core.autocrlfहै true और
2. रेपो में फ़ाइल में LFEOL है।

मेरे लिए सबसे आश्चर्य की बात है, और मुझे संदेह है, कई ईओएल समस्याओं का कारण यह है कि कोई कॉन्फ़िगरेशन नहीं है जिसमें मिश्रित ईओएल जैसे CRLF+ LFसामान्यीकृत होते हैं।

ध्यान दें कि CRकेवल "पुराने" मैक EOLs भी कभी भी रूपांतरित नहीं होते हैं।
इसका मतलब यह है कि यदि एक बुरी तरह से लिखी गई ईओएल रूपांतरण स्क्रिप्ट मिश्रित एंडिंग फ़ाइल को CRLFs + LFs के साथ परिवर्तित करने की कोशिश करती है , बस LFs को CRLFs में परिवर्तित करके , तो यह फाइल को मिश्रित मोड में "अकेला" CRs के साथ छोड़ देगी जहां भी CRLFपरिवर्तित किया गया था CRCRLF।
Git तब trueमोड में भी कुछ भी परिवर्तित नहीं करेगा , और EOL का कहर जारी है। यह वास्तव में मेरे साथ हुआ और मेरी फाइलों को वास्तव में बुरी तरह से गड़बड़ कर दिया, क्योंकि कुछ संपादकों और संकलक (जैसे VS2010) को मैक डॉल्स पसंद नहीं है।

मुझे लगता है कि इन समस्याओं को वास्तव में संभालने का एकमात्र तरीका यह है कि कभी-कभी पूरी रीपो को सामान्य करने के लिए inputया falseमोड में सभी फ़ाइलों की जांच करके , एक उचित सामान्यीकरण चलाकर और परिवर्तित फ़ाइलों को पुन: कमिट कर दें (यदि कोई हो)। विंडोज पर, संभवतः साथ काम करना फिर से शुरू करें core.autocrlf true।

Comments

उत्कृष्ट उत्तर, लेकिन एक वाक्य जिसके साथ मैं सहमत नहीं हो सकता है वह विंडोज पर है, संभवतः साथ काम करना फिर से शुरू करेंcore.autocrlf true । मेरा व्यक्तिगत रूप से मानना ​​है कि inputहमेशा इस्तेमाल किया जाना चाहिए।

— जी। डेमेकी

Answer 3

आने वाले Git 1.7.2 के साथ, "eol रूपांतरण" मोर्चे पर चीजें बदलने वाली हैं :

एक नई कॉन्फ़िगरेशन सेटिंग core.eolजोड़ी जा रही है / विकसित की जा रही है :

यह 'ऐड' core.eol"कॉन्फिग वेरिएबल 'के लिए एक प्रतिस्थापन है जो वर्तमान में pu(मेरी श्रृंखला में अंतिम एक) है। यह मानने के
बजाय कि "" core.autocrlf=true"के लिए एक प्रतिस्थापन है" * text=auto, यह इस तथ्य को स्पष्ट करता है कि autocrlfकेवल उन उपयोगकर्ताओं के लिए है जो CRLFs के साथ अपनी वर्किंग डायरेक्टरी में एक रिपॉजिटरी पर काम करना चाहते हैं जिसमें टेक्स्ट फ़ाइल का सामान्यीकरण नहीं है ।
जब इसे सक्षम किया जाता है, तो "core.eol" को अनदेखा कर दिया जाता है।

एक नया कॉन्फ़िगरेशन चर, " core.eol" का परिचय दें , जो उपयोगकर्ता को वर्किंग डायरेक्टरी में एंड-ऑफ-लाइन-सामान्यीकृत फ़ाइलों के लिए कौन सी लाइन अंत का उपयोग करने की अनुमति देता है।
यह " native" के लिए डिफॉल्ट करता है , जिसका अर्थ है कि हर जगह विंडोज और LF पर CRLF। ध्यान दें कि " core.autocrlf" ओवरराइड होता है core.eol।
इस का मतलब है कि:

[core]
  autocrlf = true

CRLFs को वर्किंग डायरेक्टरी में रखता है, भले ही core.eolवह " lf" सेट हो ।

core.eol:

textसंपत्ति सेट करने वाली फ़ाइलों के लिए काम करने वाली निर्देशिका में उपयोग करने के लिए लाइन को समाप्त प्रकार सेट करता है।
विकल्प 'lf', 'crlf' और 'native' हैं, जो प्लेटफ़ॉर्म की मूल पंक्ति को समाप्त करने का उपयोग करता है।
डिफ़ॉल्ट मान है native।

---

अन्य प्रस्तावों पर विचार किया जा रहा है :

1.8 के लिए, मैं बनाने पर विचार करेगा core.autocrlfसिर्फ सामान्य चालू करने और कार्यशील निर्देशिका core.eol करने का निर्णय न खत्म होने वाली लाइन छोड़ देते हैं, लेकिन यह है कि होगा लोगों की व्यवस्था टूट गया।

---

git 2.8 (मार्च 2016) core.autocrlfईओल को प्रभावित करने के तरीके में सुधार करता है :

देखें प्रतिबद्ध 817a0c7 (23 फ़रवरी 2016), 6e336a5 प्रतिबद्ध , df747b8 प्रतिबद्ध , df747b8 प्रतिबद्ध , (10 फ़र, 2016) df747b8 प्रतिबद्ध , df747b8 प्रतिबद्ध (10 फ़र, 2016), और 4b4024f प्रतिबद्ध , bb211b4 प्रतिबद्ध , 92cce13 प्रतिबद्ध , 320d39c प्रतिबद्ध , 4b4024f प्रतिबद्ध , bb211b4 प्रतिबद्ध , 92cce13 प्रतिबद्ध , 320d39c प्रतिबद्ध (05 फ़र, 2016) द्वारा टॉरस्टेन Bögershausen ( tboegi) ।
^{(द्वारा विलय Junio सी Hamano - gitster- में c6b94eb प्रतिबद्ध, 26 फरवरी 2016)}

convert.c: रिफलेक्टर crlf_action

के निर्धारण और उपयोग को प्रतिबिंबित करता है crlf_action।
आज, जब crlfफ़ाइल पर कोई " " विशेषता सेट नहीं की जाती है, तब तक crlf_actionसेट किया जाता है CRLF_GUESS। CRLF_UNDEFINEDइसके बजाय का उपयोग करें , और पहले की तरह " text" या " eol" खोजें।

पुराने CRLF_GUESSउपयोग को बदलें :

CRLF_GUESS && core.autocrlf=true -> CRLF_AUTO_CRLF
CRLF_GUESS && core.autocrlf=false -> CRLF_BINARY
CRLF_GUESS && core.autocrlf=input -> CRLF_AUTO_INPUT

परिभाषित करके और अधिक स्पष्ट करें कि क्या है, क्या है:

- CRLF_UNDEFINED : No attributes set. Temparally used, until core.autocrlf
                   and core.eol is evaluated and one of CRLF_BINARY,
                   CRLF_AUTO_INPUT or CRLF_AUTO_CRLF is selected
- CRLF_BINARY    : No processing of line endings.
- CRLF_TEXT      : attribute "text" is set, line endings are processed.
- CRLF_TEXT_INPUT: attribute "input" or "eol=lf" is set. This implies text.
- CRLF_TEXT_CRLF : attribute "eol=crlf" is set. This implies text.
- CRLF_AUTO      : attribute "auto" is set.
- CRLF_AUTO_INPUT: core.autocrlf=input (no attributes)
- CRLF_AUTO_CRLF : core.autocrlf=true  (no attributes)

---

जैसा कि torek टिप्पणियों में जोड़ता है :

ये सभी अनुवाद (किसी भी ईओएल रूपांतरण eol=या autocrlfसेटिंग्स से, और " clean" फिल्टर) चलाए जाते हैं जब फाइलें कार्य-वृक्ष से सूचकांक में स्थानांतरित होती हैं , अर्थात, समय के git addबजाय git commit।
(ध्यान दें कि git commit -aया --onlyया --includeउस समय सूची में जोड़ना फ़ाइलों करते हैं, हालांकि।)

उस पर अधिक के लिए, " आटोक्रॉल्फ और ईओएल के बीच अंतर क्या है " देखें ।

Comments

यह, दुर्भाग्य से, मेरे लिए स्पष्टता नहीं जोड़ता है। ऐसा लगता है जैसे वे कह रहे हैं कि वर्तमान कार्यान्वयन के साथ समस्याएं हैं (यह स्पष्ट नहीं है कि वे समस्याएं क्या हैं) और वे उन अनिर्दिष्ट समस्याओं को हल करने के प्रयास में जटिलता बढ़ा रहे हैं। मेरी राय में, core.autocrlf की सेटिंग पहले से ही जटिल और कम-दस्तावेज है और यह स्थिति खराब होती दिखाई दे रही है। फिर से सिर के लिए धन्यवाद।

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

यह एक संतोषजनक समाधान की तरह प्रतीत नहीं होता है, और लगता है कि core.autocrlf जैसी ही समस्याएं हैं। मेरी प्राथमिकता यह होगी कि अगर गिट अपने आप कभी किसी चीज को संशोधित नहीं करेगा, लेकिन यह उस उपयोगकर्ता को चेतावनी देगा जो गलत लाइन एंडिंग को जोड़ना या प्रतिबद्ध करना चाहता है। तो आपको "गलत" लाइन के अंत को जोड़ने के लिए "गिट ऐड" की अनुमति देने के लिए एक कमांडलाइन विकल्प की आवश्यकता होगी। (शायद git add यह git कमिट की तुलना में जाँच करने के लिए बेहतर जगह है)

— donquixote

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

— दान

@donquixote फिर, मैं सहमत हूं। लेकिन core.eol"स्वचालित रूप से संशोधन" के बारे में केवल वही है जो आप स्पष्ट रूप से एक .gitattributesफ़ाइल में घोषित करते हैं । यह अलग है core.autocrlfजो रेपो में किसी भी फाइल पर लागू होता है । यह एक घोषणात्मक प्रक्रिया है।

— वॉन सी सी

@donquixote: मुझे एहसास है कि यह काफी पुराना है लेकिन मैं केवल आपकी टिप्पणी अब पढ़ता हूं। वास्तव में, ये सभी अनुवाद (ईओएल = या आटोक्रॉफ़ल सेटिंग्स से कोई भी ईओएल रूपांतरण, और "क्लीन" फिल्टर) चलाए जाते हैं जब फाइलें काम के पेड़ से इंडेक्स तक जाती हैं, अर्थात समय के git addबजाय git commit। (ध्यान दें कि git commit -aया --onlyया --include, उस समय सूची में जोड़ना फ़ाइलों करना यद्यपि।) क्या यह की कीमत, तुम और मैं और लिनुस टोर्वाल्ड सब एक VCS के विचार से नफरत के लिए कभी संशोधित क्या प्रतिबद्ध किया जा रहा है। लेकिन वहाँ उन सभी विंडोज उपयोगकर्ताओं ... :-) हैं

— torek

Answer 4

core.autocrlfमान OS प्रकार पर निर्भर नहीं करता है लेकिन Windows डिफ़ॉल्ट मान पर trueऔर लिनक्स के लिए है - input। मैंने प्रतिबद्ध और चेकआउट मामलों के लिए 3 संभावित मानों का पता लगाया और यह परिणामी तालिका है:

╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ core.autocrlf ║     false    ║     input    ║     true     ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║               ║ LF   => LF   ║ LF   => LF   ║ LF   => LF   ║
║ git commit    ║ CR   => CR   ║ CR   => CR   ║ CR   => CR   ║
║               ║ CRLF => CRLF ║ CRLF => LF   ║ CRLF => LF   ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║               ║ LF   => LF   ║ LF   => LF   ║ LF   => CRLF ║
║ git checkout  ║ CR   => CR   ║ CR   => CR   ║ CR   => CR   ║
║               ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝

Comments

शब्दों में संक्षिप्त सारांश: CRअकेले फाइलों को कभी नहीं छुआ जाता है। falseलाइन एंडिंग को कभी नहीं छूता है। trueहमेशा के रूप में करता है LFऔर के रूप में बाहर की जाँच करता है CRLF। और inputहमेशा के रूप में करता है LFऔर के रूप में बाहर की जाँच करता है।

— फुरकान कांबे

Answer 5

यहाँ यह मेरी समझ है अब तक, अगर यह किसी की मदद करता है।

core.autocrlf=true तथा core.safecrlf = true

आपके पास एक रिपॉजिटरी है जहां सभी लाइन अंत समान हैं , लेकिन आप विभिन्न प्लेटफार्मों पर काम करते हैं। Git सुनिश्चित करेगा कि आपकी लाइन्स की एंडिंग आपके प्लेटफ़ॉर्म के लिए डिफ़ॉल्ट में परिवर्तित हो गई है। यह बात क्यों है? मान लीजिए कि आप एक नई फ़ाइल बनाते हैं। आपके प्लेटफ़ॉर्म पर टेक्स्ट एडिटर अपनी डिफ़ॉल्ट लाइन एंडिंग्स का उपयोग करेगा। जब आप इसे चेक करते हैं, यदि आपके पास core.autocrlf को सही पर सेट नहीं किया गया है, तो आपने किसी प्लेटफ़ॉर्म पर किसी व्यक्ति के लिए असंगतता को समाप्त करने वाली एक पंक्ति शुरू की है जो एक अलग लाइन को समाप्त करने में चूक करता है। मैं हमेशा सुरक्षित भी सेट करता हूं, क्योंकि मैं जानना चाहता हूं कि क्रॉलर संचालन प्रतिवर्ती है। इन दो सेटिंग्स के साथ, git आपकी फ़ाइलों को संशोधित कर रहा है, लेकिन यह सत्यापित करता है कि संशोधन प्रतिवर्ती हैं ।

core.autocrlf=false

आपके पास एक रिपॉजिटरी है जिसमें पहले से ही मिश्रित लाइन एंडिंग की जांच की गई है और गलत लाइन एंडिंग को ठीक करने से अन्य चीजें टूट सकती हैं। इस मामले में लाइन एंडिंग्स को रूपांतरित करने के लिए इसका सबसे अच्छा तरीका नहीं बताना, क्योंकि तब यह समस्या को हल कर देगा जिसे इसे हल करने के लिए डिज़ाइन किया गया था - बनाने से पढ़ने में आसानी होती है और कम दर्दनाक विलय होता है। इस सेटिंग के साथ, git आपकी फ़ाइलों को संशोधित नहीं करता है ।

core.autocrlf=input

मैं इसका उपयोग नहीं करता हूं क्योंकि इसका कारण एक उपयोग के मामले को कवर करना है जहां आपने एक फ़ाइल बनाई है जिसमें CRLF लाइन अंत एक प्लेटफ़ॉर्म पर है जो LF लाइन अंत के लिए डिफ़ॉल्ट है। मैं अपने पाठ संपादक को हमेशा बनाने के बजाय पसंद करता हूं कि प्लेटफ़ॉर्म की लाइन समाप्त होने वाली चूक के साथ हमेशा नई फ़ाइलों को बचाएं।

Answer 6

नहीं, @jmlane का उत्तर गलत है।

के लिए Checkin (git add, git commit):

1. यदि textसंपत्ति है Set, Set value to 'auto', तो रूपांतरण तब होता है जब फ़ाइल 'CRLF' के साथ प्रतिबद्ध हो गई हो
2. अगर textसंपत्ति है Unset: कुछ भी नहीं होता है, तो इसके लिए ईन करेंCheckout
3. यदि textसंपत्ति है Unspecified, तो रूपांतरण पर निर्भर करता हैcore.autocrlf
   1. यदि autocrlf = input or autocrlf = true, रूपांतरण केवल तब होता है जब रिपॉजिटरी में फ़ाइल 'LF' होती है, यदि यह 'CRLF' हो, तो कुछ भी नहीं होगा।
   2. अगर autocrlf = false, कुछ नहीं होता है

के लिए Checkout:

1. अगर textसंपत्ति है Unset: कुछ नहीं होता है।
2. यदि textसंपत्ति है Set, Set value to 'auto: यह पर निर्भर करता है core.autocrlf, core.eol।
   1. core.autocrlf = input: कुछ नहीं होता है
   2. core.autocrlf = true: रूपांतरण केवल तब होता है जब रिपॉजिटरी में फ़ाइल 'LF', 'LF' -> 'CRLF' होती है
   3. core.autocrlf = false: रूपांतरण केवल तब होता है जब रिपॉजिटरी में फ़ाइल 'LF', 'LF' -> core.eol
3. अगर text संपत्ति है Unspecified, तो यह निर्भर करता हैcore.autocrlf ।
   1. बराबर 2.1
   2. बराबर 2.2
   3. कोई नहीं, कुछ भी नहीं होता है, textसंपत्ति होने पर core.eol प्रभावी नहीं हैUnspecified

डिफ़ॉल्ट व्यवहार

तो डिफ़ॉल्ट व्यवहार textसंपत्ति है Unspecifiedऔर core.autocrlf = false:

1. चेकइन के लिए, कुछ भी नहीं होता है
2. चेकआउट के लिए, कुछ भी नहीं होता है

निष्कर्ष

1. अगर text संपत्ति सेट की जाती है, तो चेकइन का व्यवहार स्वयं पर निर्भर करता है, न कि ऑटोक्रॉफ्ट पर
2. ऑटोक्रॉफ्ट या core.eol चेकआउट व्यवहार के लिए है, और autocrlf> core.eol

Answer 7

लिनक्स और खिड़कियों दोनों पर कुछ परीक्षण किए। मैं LF में समाप्त होने वाली लाइनों और CRLF में समाप्त होने वाली लाइनों वाली एक परीक्षण फ़ाइल का उपयोग करता हूं।
फ़ाइल के लिए प्रतिबद्ध है, हटा दिया और फिर बाहर की जाँच की। Core.autocrlf का मान प्रतिबद्ध होने से पहले और चेकआउट से पहले भी निर्धारित होता है। परिणाम नीचे है।

commit core.autocrlf false, remove, checkout core.autocrlf false: LF=>LF   CRLF=>CRLF  
commit core.autocrlf false, remove, checkout core.autocrlf input: LF=>LF   CRLF=>CRLF  
commit core.autocrlf false, remove, checkout core.autocrlf true : LF=>LF   CRLF=>CRLF  
commit core.autocrlf input, remove, checkout core.autocrlf false: LF=>LF   CRLF=>LF  
commit core.autocrlf input, remove, checkout core.autocrlf input: LF=>LF   CRLF=>LF  
commit core.autocrlf input, remove, checkout core.autocrlf true : LF=>CRLF CRLF=>CRLF  
commit core.autocrlf true, remove, checkout core.autocrlf false: LF=>LF   CRLF=>LF  
commit core.autocrlf true, remove, checkout core.autocrlf input: LF=>LF   CRLF=>LF  
commit core.autocrlf true,  remove, checkout core.autocrlf true : LF=>CRLF CRLF=>CRLF