CRLF के साथ LF की जगह git

Question

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

मैंने तब निर्यात को नंगे रिपोजिटरी डायरेक्टरी में पेस्ट किया, और किया:

git add -A

मुझे तब यह कहते हुए संदेशों की एक सूची मिली:

LF को CRLF द्वारा प्रतिस्थापित किया जाएगा

इस रूपांतरण के क्या प्रभाव हैं? यह Visual Studio में एक .NET समाधान है।

Comments

@apphacker क्योंकि दो फाइलों को अलग करने पर लाइन-एंडिंग को मानकीकृत करना स्वयं को बदलने की तुलना में कम कष्टप्रद है। (और निश्चित रूप से, यदि आप असहमत हैं, तो आप core.autocrlf फीचर को बंद रख सकते हैं)।

— RJFalconer

जब तक पूरी लाइन को नहीं छुआ जाता, तब तक लाइन अंत अलग-अलग क्यों होता

— Bjorn

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

— MatrixFrog

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

— मार्ख

केवल आधुनिक संपादक के बारे में मुझे पता है कि गलत काम करता है विजुअल स्टूडियो। विजुअल स्टूडियो खुशी से LF लाइन एंडिंग वाली फाइल खोल देगा। यदि आप फिर नई लाइनें सम्मिलित करते हैं, तो यह CRLF सम्मिलित करेगा, और मिश्रित लाइन समाप्ति को बचाएगा। Microsoft इसे ठीक करने से इंकार कर देता है, जो अन्यथा बहुत अच्छे IDE पर एक बहुत बड़ा दोष है: - (

— जॉन वाट

Answer 1

ये संदेश core.autocrlfविंडोज़ पर गलत डिफ़ॉल्ट मान के कारण हैं ।

यह autocrlfहै कि लाइन एंडिंग रूपांतरणों को पारदर्शी तरीके से संभालना है। और यह करता है!

बुरी खबर : मूल्य को मैन्युअल रूप से कॉन्फ़िगर करने की आवश्यकता है।
अच्छी खबर : इसे केवल एक बार प्रति इंस्टॉलेशन के अनुसार किया जाना चाहिए (प्रति प्रोजेक्ट सेटिंग भी संभव है)।

कैसे autocrlfकाम करता है :

core.autocrlf=true:      core.autocrlf=input:     core.autocrlf=false:

        repo                     repo                     repo
      ^      V                 ^      V                 ^      V
     /        \               /        \               /        \
crlf->lf    lf->crlf     crlf->lf       \             /          \      
   /            \           /            \           /            \

यहां crlf= जीत-शैली अंत-रेखा मार्कर, lf= यूनिक्स-शैली (और मैक ओएसएक्स)।

( crऊपर दिए गए तीन विकल्पों में से किसी के लिए भी प्रभावित नहीं है)

यह चेतावनी कब दिखाई जाती है (विंडोज के तहत)

    - autocrlf= trueयदि आपकी किसी lfफाइल (= RARELY) में यूनिक्स-शैली है,
    - autocrlf= inputयदि आपकी किसी crlfफाइल में (= लगभग हमेशा) जीत शैली है,
    - autocrlf= false- - कभी नहीं!

इस चेतावनी का क्या मतलब है

चेतावनी " LF को CRLF द्वारा प्रतिस्थापित किया जाएगा " कहता है कि आप (होने autocrlf= true) ने कमिट-चेकआउट चक्र के बाद अपना यूनिक्स-शैली LF खो दिया होगा (यह विंडोज़-शैली CRLF द्वारा प्रतिस्थापित किया जाएगा)। Git आपको विंडोज़ के तहत यूनिक्स-शैली LF का उपयोग करने की उम्मीद नहीं करता है।

चेतावनी " CRLF को LF द्वारा प्रतिस्थापित किया जाएगा " का कहना है कि आप (होने autocrlf= input) एक कम-चेकआउट चक्र के बाद अपनी विंडोज़-शैली CRLF खो देंगे (यह यूनिक्स-शैली LF द्वारा प्रतिस्थापित किया जाएगा)। inputखिड़कियों के नीचे उपयोग न करें ।

फिर भी एक और तरीका है यह दिखाने के लिए कि कैसे autocrlfकाम करता है

1) true:             x -> LF -> CRLF
2) input:            x -> LF -> LF
3) false:            x -> x -> x

जहाँ x या तो CRLF (विंडोज़-शैली) या LF (यूनिक्स-शैली) और तीर के लिए खड़ा है

file to commit -> repository -> checked out file

कैसे ठीक करना है

डिफ़ॉल्ट मान core.autocrlfgit स्थापना के दौरान चुना जाता है और सिस्टम-वाइड gitconfig ( %ProgramFiles(x86)%\git\etc\gitconfig) में संग्रहीत किया जाता है । इसके अलावा वहाँ हैं (निम्नलिखित क्रम में कैस्केडिंग):

   - "वैश्विक" (प्रति-उपयोगकर्ता) gitconfig पर स्थित है ~/.gitconfig, फिर भी एक और
   - "वैश्विक" (प्रति-उपयोगकर्ता) gitconfig पर $XDG_CONFIG_HOME/git/configया    - $HOME/.config/git/configऔर
"स्थानीय" (प्रति-रेपो) gitconfig में .git/configकाम कर रहा है।

इसलिए, git config core.autocrlfवर्तमान में उपयोग किए गए मूल्य की जांच करने के लिए काम करने वाले डायर में लिखें और

   - autocrlf=falseसिस्टम-वाइड gitconfig # प्रति-सिस्टम समाधान
   - git config --global core.autocrlf false            # प्रति-उपयोगकर्ता समाधान
   - git config --local core.autocrlf false              # प्रति-प्रोजेक्ट समाधान जोड़ें

चेतावनियाँ
- git configसेटिंग्स द्वारा gitattributesसेटिंग्स को ओवरराइड किया जा सकता है ।
- crlf -> lfरूपांतरण केवल तब होता है जब नई फाइलें जोड़ते हैं, crlfरेपो में पहले से मौजूद फाइलें प्रभावित नहीं होती हैं।

Moral (Windows के लिए):
    - उपयोग करें core.autocrlf= trueयदि आप यूनिक्स के तहत इस परियोजना का उपयोग करने की योजना बना रहे हैं (और यूनिक्स लाइन एंडिंग का उपयोग करने के लिए अपने संपादक / IDE को कॉन्फ़िगर करने के लिए तैयार नहीं हैं),
    - उपयोग करें core.autocrlf= falseयदि आप केवल Windows के तहत इस परियोजना का उपयोग करने की योजना बनाते हैं ( या आपने यूनिक्स लाइन एंडिंग का उपयोग करने के लिए अपने संपादक / आईडीई को कॉन्फ़िगर किया है),
    - कभी भी उपयोग न करें core.autocrlf= inputजब तक कि आपके पास एक अच्छा कारण न हो ( जैसे कि यदि आप विंडोज़ के तहत यूनिक्स उपयोगिताओं का उपयोग कर रहे हैं या यदि आप मेकफाइल्स मुद्दों में भाग लेते हैं),

पुनश्च विंडोज के लिए गिट स्थापित करते समय क्या चुनना है?
यदि आप यूनिक्स के तहत अपनी किसी भी परियोजना का उपयोग नहीं करने जा रहे हैं, तो डिफ़ॉल्ट पहले विकल्प से सहमत न हों । तीसरा एक चुनें ( जैसा कि चेकआउट है, वैसे ही कमिट करें )। आपको यह संदेश दिखाई नहीं देगा। कभी।

पीपीएस मेरी निजी प्राथमिकता संपादक / आईडीई को यूनिक्स-शैली की समाप्ति और सेटिंग core.autocrlfका उपयोग करने के लिए कॉन्फ़िगर कर रही हैfalse ।

Comments

इस राशि को प्राप्त करने के लिए मैंने जितना समय खर्च किया है, मैं एक कोर के लिए उम्मीद कर रहा था। क्राल = रैकऑफ़ ;-)

— पांडा 31

मैंने सामग्री का पुनर्गठन किया, शायद इस तरह से पढ़ना आसान होगा

— एंटनी हैचकिंस

क्षमा करें, मुझे आशा है कि मेरी टिप्पणी आपके उत्तर की आलोचना के रूप में नहीं ली गई थी। इस उत्तर को खोजने से पहले, "इसे दूर करने के लिए" मेरा मतलब है।

— पांडावुड

यह कितना भ्रामक है। मैंने अपने संपादक में LF सेट किया है। सभी रेपो कोड LF का उपयोग करते हैं। वैश्विक आटोक्रॉफल्स झूठे के लिए सेट है और मेरे घर में कोर gitconfig झूठी पर सेट है। लेकिन मुझे अभी भी संदेश मिलता है कि एलएफ को

— सीआरएलएफ के

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

— हुब्रो

Answer 2

Git के तीन तरीके हैं कि वह लाइन एंडिंग के साथ कैसे व्यवहार करता है:

$ git config core.autocrlf
# that command will print "true" or "false" or "input"

आप उपरोक्त कमांड लाइन में एक अतिरिक्त पैरामीटर जोड़कर trueया उपयोग करने के लिए मोड सेट कर सकते हैं false।

अगर core.autocrlf यह सही है, तो इसका मतलब है कि किसी भी समय आप git repo में एक फ़ाइल जोड़ते हैं कि git सोचता है कि यह एक टेक्स्ट फ़ाइल है, यह सभी CRLF लाइन एंडिंग्स को कमिट करने से पहले सिर्फ LF में बदल देगा। जब भी आप git checkoutकुछ करते हैं, सभी पाठ फ़ाइलों में स्वचालित रूप से उनकी LF लाइन अंत CRLF अंत में परिवर्तित हो जाएगी। यह उन प्लेटफार्मों के पार एक परियोजना के विकास की अनुमति देता है जो बिना किसी शोर-शराबे के अलग-अलग लाइन-एंडिंग स्टाइल का उपयोग करते हैं क्योंकि प्रत्येक एडिटर लाइन एंडिंग स्टाइल को बदल देता है क्योंकि लाइन एंडिंग स्टाइल हमेशा LF होता है।

इस सुविधाजनक रूपांतरण का साइड-इफ़ेक्ट, और यह वह चेतावनी है जिसे आप देख रहे हैं, यह है कि यदि आपके द्वारा लिखी गई एक टेक्स्ट फ़ाइल में मूल रूप से CRLF के बजाय LF एंडिंग्स हैं, तो इसे हमेशा की तरह LF के साथ संग्रहीत किया जाएगा, लेकिन जब जाँच की जाती है बाद में इसमें CRLF की समाप्ति होगी। सामान्य पाठ फ़ाइलों के लिए यह आमतौर पर ठीक है। इस मामले में चेतावनी "आपकी जानकारी के लिए" है, लेकिन अगर git गलत तरीके से एक बाइनरी फ़ाइल को एक टेक्स्ट फ़ाइल के रूप में आंकता है, तो यह एक महत्वपूर्ण चेतावनी है क्योंकि git तब आपकी बाइनरी फ़ाइल को दूषित कर रहा होगा।

यदि core.autocrlfइसे गलत पर सेट किया जाता है, तो कोई भी लाइन-एंड रूपांतरण कभी नहीं किया जाता है, इसलिए टेक्स्ट फ़ाइलों की जाँच की जाती है। यह आमतौर पर ठीक काम करता है, जब तक कि आपके सभी डेवलपर्स लिनक्स पर या विंडोज पर सभी होते हैं। लेकिन मेरे अनुभव में मैं अभी भी मिश्रित लाइन एंडिंग के साथ पाठ फ़ाइलों को प्राप्त करता हूं जो समस्याओं का कारण बनते हैं।

मेरी व्यक्तिगत प्राथमिकता विंडोज डेवलपर के रूप में सेटिंग को चालू करना छोड़ना है।

अद्यतन जानकारी के लिए http://kernel.org/pub/software/scm/git/docs/git-config.html देखें जिसमें "इनपुट" मान शामिल है।

Comments

जैसा कि यहां कहा गया है ( stackoverflow.com/questions/1249932/… ), मैं सम्मानपूर्वक असहमत हो जाऊंगा और उस सेटिंग को बंद करने के लिए छोड़ दूंगा (और नोटपैड ++ या किसी अन्य संपादक से निपटने के लिए उपयोग कर सकता हूं - और इसे छोड़ दें - जो भी अंत है यह पाता है)

— VONC

मुझे यह उत्तर पसंद है, और सच के लिए सेट आटोफ्लोर छोड़ना पसंद करते हैं। एक विकल्प के रूप में, क्या चेतावनी संदेशों को स्वचालित रूप से मारने का एक तरीका है?

— क्रिस्च

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

— सेह

एक और अधिक स्थायी समाधान के लिए अपने .gitconfig को इसमें बदलें: [कोर] ऑटोक्रॉफ्ट = झूठा

— RBZ

क्या सिर्फ चेतावनी को दरकिनार करने का कोई आसान तरीका है? मैं इसे सच करना चाहता हूं और जानता हूं कि मैंने इसे सच कर दिया है। मुझे हर समय सभी चेतावनियाँ देखने की आवश्यकता नहीं है ... यह ठीक है, वास्तव में ...: पी

— उमाएन

Answer 3

यदि आपने पहले से ही कोड की जाँच कर ली है, तो फ़ाइलें पहले से ही अनुक्रमित हैं। अपनी git सेटिंग बदलने के बाद, रन करके कहें:

git config --global core.autocrlf input 

आपको अनुक्रमणिका को ताज़ा करना चाहिए

git rm --cached -r . 

और git इंडेक्स को फिर से लिखें

git reset --hard

https://help.github.com/articles/dealing-with-line-endings/#refreshing-a-repository-after-changing-line-endings

नोट: यह आपके स्थानीय परिवर्तनों को हटा देगा, ऐसा करने से पहले उन्हें रोकना पर विचार करें।

Comments

विन्यास अर्थ के बारे में एक बड़ी चर्चा के बजाय, इसे सरल, क्रॉस-प्लेटफ़ॉर्म, FIX के लिए स्पष्ट तरीके से धन्यवाद।

— एरिस

अगर यह रीसेट हो जाता है - तो क्या यह संभव है कि मेरा स्थानीय परिवर्तन खो जाएगा? मैं ऊपर दिए गए सभी टिप्पणी के बाद का पालन करता

— हूं

हां आपके स्थानीय परिवर्तन खो जाएंगे। -हार्ड पैरामीटर इंडेक्स और वर्किंग ट्री को रीसेट करता है इसलिए ट्रैक की गई फ़ाइलों में कोई भी परिवर्तन छोड़ दिया जाएगा। git-scm.com/docs/git-reset

— जैक्स

का अर्थ क्या है git rm --cached -r .? क्यों git reset --hardपर्याप्त नहीं है?

— गवेंको

@gavenkoa @max आपको जरूरत है git rm --cached -r .अगर आप सेटिंग git reset --hardबदलने के बाद करते core.autocrlfहैं, तो यह लाइन एंडिंग्स को फिर से नहीं बदलेगा । आपको git इंडेक्स को साफ़ करने की आवश्यकता है।

— 23

Answer 4

git config core.autocrlf false

Comments

इसे रिपॉजिटरी रूट के अंदर चलाना सुनिश्चित करें

— हम्मद खान

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

— ज़ोरान पावलोविक

मुझे एक त्रुटि मिलती है "घातक: एक गिट निर्देशिका में नहीं"। मैंने C: \ Program Files \ Git और C: \ Program Files \ Git \ bin

— pixelwiz

@mbb सेटिंग सिर्फ इस मुद्दे को आपके प्रोजेक्ट के प्रत्येक उपयोगकर्ता autcrlfको सजा देती है false।

— jpaugh

@pixelwiz: यह कमांड केवल प्रोजेक्ट के लिए प्रॉपर्टी सेट कर रहा है (इसलिए इसे चलाने के लिए आपको git रिपॉजिटरी के अधीन होना चाहिए)। यदि आप इसे विश्व स्तर पर स्थापित करना चाहते हैं, तो git config --global core.autocrlf falseइसके बजाय उपयोग करें ।

— माइकल पोला

Answer 5

दोनों unix2dos और dos2unix gitbash के साथ खिड़कियों में उपलब्ध है। आप UNIX (LF) -> DOS (CRLF) रूपांतरण करने के लिए निम्न कमांड का उपयोग कर सकते हैं। इसलिए, आपको चेतावनी नहीं मिलेगी।

unix2dos filename

या

dos2unix -D filename

लेकिन, किसी भी मौजूदा CRLF फ़ाइल पर इस कमांड को न चलाएं, तो आपको हर दूसरी पंक्ति में खाली नईलाइनें मिलेंगी।

dos2unix -D filenameहर ऑपरेटिंग सिस्टम के साथ काम नहीं करेगा। कृपया संगतता के लिए इस लिंक को देखें।

यदि किसी कारण से आपको कमांड को मजबूर करने की आवश्यकता है तो उपयोग करें --force। यदि यह अमान्य है तो उपयोग करें -f।

Comments

यह क्या करता है?

— सलमान वॉन अब्बास

यहां बताया गया है कि सहायता विकल्प क्या कहता है: `--u2d, -D प्रदर्शन UNIX -> DOS रूपांतरण`

— लैरी बैटल

@Rifat मैं भ्रमित हूँ। आपकी टिप्पणी कहती है कि dos2unix -Dविंडोज़ लाइन एंडिंग को लिनक्स लाइन एंडिंग में बदल देगी। क्या यह DOS (CRLF) -> UNIX (LF) रूपांतरण के समान नहीं है। हालाँकि, यह dos2unix -hबताता है कि -DUNIX (LF) -> DOS (CRLF) रूपांतरण करेगा। dos2unix अधिक जानकारी: gopherproxy.meulie.net/sdf.org/0/users/pmyshkin/dos2unix

— लैरी बैटल

@LarryBattle हाँ, आप सही हैं -D के बारे में। वास्तव में, मैंने जवाब पोस्ट किया जब मैं एक विंडोज़ उपयोगकर्ता था। और, मैंने एक साल से अधिक समय बाद टिप्पणी की जब मैं एक मैक उपयोगकर्ता हूं: डी बीटीडब्ल्यू, स्पष्टीकरण के लिए धन्यवाद।

— रिफत

इसने मेरे लिए काम किया। मैं Cygwin का उपयोग कर रहा हूं, जो -D स्विच का समर्थन नहीं करता है - लेकिन "unix2dos" कमांड है, जो समान काम करता है। काश मुझे पता होता कि क्या समस्या है, हालांकि - मेरे पास core.autocrlf = false है और यह एक Windows- केवल रिपॉजिटरी है।

— रिचर्ड बीयर

Answer 6

मुझे लगता है कि @ बासिलोनास का जवाब करीब है लेकिन पुराना है (कम से कम मैक पर)।

~ / .Gitconfig फ़ाइल खोलें और safecrlfगलत पर सेट करें

[core]
       autocrlf = input
       safecrlf = false

वह * इसे स्पष्ट रूप से लाइन चार के अंत की अनदेखी करेगा (मेरे लिए काम किया, वैसे भी)।

Comments

यह safecrlf(एक 'एफ' के साथ) होना चाहिए

— अल्पनागो

Answer 7

एक लाइन अंत पर GitHub के लेख आमतौर पर उल्लेख किया जब इस विषय के बारे में बात कर रहा है।

अक्सर अनुशंसित core.autocrlfकॉन्फ़िगरेशन सेटिंग का उपयोग करने के साथ मेरा व्यक्तिगत अनुभव बहुत मिश्रित था।

मैं अलग-अलग समय में Windows और UNIX दोनों परियोजनाओं से निपटने के लिए, Cygwin के साथ Windows का उपयोग कर रहा हूं। यहां तक ​​कि मेरे विंडोज प्रोजेक्ट भी कभी-कभी bashशेल स्क्रिप्ट का उपयोग करते हैं, जिसके लिए UNIX (LF) लाइन एंडिंग की आवश्यकता होती है।

GitHub की सिफारिश का उपयोग करना core.autocrlfWindows के लिए सेटिंग , अगर मैं UNIX प्रोजेक्ट की जांच करता हूं (जो कि पूरी तरह से Cygwin पर काम करता है - या शायद मैं अपने लिनक्स सर्वर पर उपयोग होने वाले प्रोजेक्ट में योगदान दे रहा हूं), तो पाठ फ़ाइलों को विंडोज (CFF) के साथ जांचा जाता है ) लाइन एंडिंग, समस्याएं पैदा करना।

मूल रूप से, मेरे जैसे मिश्रित वातावरण के core.autocrlfलिए, किसी भी विकल्प के लिए वैश्विक सेट करना कुछ मामलों में अच्छी तरह से काम नहीं करेगा। यह विकल्प एक स्थानीय (रिपॉजिटरी) git config पर सेट किया जा सकता है, लेकिन यहां तक ​​कि यह एक ऐसी परियोजना के लिए पर्याप्त नहीं होगा जिसमें Windows- और UNIX- संबंधित सामान शामिल हैं (जैसे कि मेरे पास कुछ के साथ एक Windows परियोजना हैbash उपयोगिता स्क्रिप्ट के )।

सबसे अच्छा विकल्प जो मैंने पाया है वह प्रति-रिपोजिटरी .gitattributes फाइलें बनाना है। GitHub लेख यह उल्लेख है।
उस लेख से उदाहरण:

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

# Explicitly declare text files you want to always be normalized and converted
# to native line endings on checkout.
*.c text
*.h text

# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf

# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary

मेरी एक परियोजना के भंडार में:

* text=auto

*.txt         text eol=lf
*.xml         text eol=lf
*.json        text eol=lf
*.properties  text eol=lf
*.conf        text eol=lf

*.awk  text eol=lf
*.sed  text eol=lf
*.sh   text eol=lf

*.png  binary
*.jpg  binary

*.p12  binary

यह स्थापित करने के लिए कुछ और चीजें हैं, लेकिन इसे प्रोजेक्ट के अनुसार एक बार करें, और किसी भी ओएस पर किसी भी योगदानकर्ता को इस परियोजना के साथ काम करते समय लाइन एंडिंग से कोई परेशानी नहीं होनी चाहिए।

Comments

अब इस में चल रहे हैं, अन्य मूल पाठ फ़ाइलों के बीच Cygwin लिपियों के साथ एक रेपो का प्रबंधन करने की कोशिश कर रहा है। आप बिना एक्सटेंशन वाली फ़ाइलों को कैसे संभालेंगे (उदाहरण के लिए "fstab", "sshd_config")? लिंक किया गया लेख उस परिदृश्य को कवर नहीं करता है।

— माइक लूक्स

@ माइकलाइक्स इस विधि को आजमाएं: stackoverflow.com/a/44806034/4377192

— Gene Pavlovsky

मैंने पाया कि text=false eol=falseकुछ हद तक इसी तरह काम किया binary। क्या यह सही है? यह इंगित करने के लिए उपयोगी हो सकता है "मुझे पता है कि ये पाठ फ़ाइलें हैं, लेकिन मैं उन्हें सामान्यीकृत नहीं करना चाहता हूं"

— joeytwiddle

Answer 8

Vim में फ़ाइल खोलें (उदाहरण के लिए :e YOURFILEENTER), फिर

:set noendofline binary
:wq

Comments

बस के साथ संपादन vimसभी लाइन समाप्त होने को छोड़ देगा।

— आँख की

मैं कुछ Cocoapods फ़ाइलों के साथ यह समस्या रहा है। उपर्युक्त अधिकांश उनमें से तय किए गए; बाकी के लिए, s / {control-v} {control-m} // ने चाल चली। दो कंट्रोल कोड मिलकर ^ M को बनाते हैं जो कि OS X पर हममें से अक्सर लोग विंडोज फाइल्स में देखते हैं।

— २२

Answer 9

मुझे यह समस्या भी हुई।

एसवीएन रूपांतरण को समाप्त करने वाली कोई भी लाइन नहीं करता है, इसलिए फाइलें CRLF लाइन एंडिंग के साथ प्रतिबद्ध हैं। यदि आप प्रोजेक्ट को लगाने के लिए git-svn का उपयोग करते हैं तो CRLF एंडिंग git रिपॉजिटरी में बनी रहती है, जो कि स्टेट git को खुद को खोजने की उम्मीद नहीं है - डिफ़ॉल्ट में केवल यूनिक्स (linux (LF)) लाइन एंडिंग हैं आगमन की सूचना दिया।

जब आप खिड़कियों पर फ़ाइलों की जांच करते हैं, तो आटोक्रॉफ़ल रूपांतरण फ़ाइलों को बरकरार रखता है (जैसा कि उनके पास पहले से ही वर्तमान प्लेटफ़ॉर्म के लिए सही अंत है), हालांकि प्रक्रिया जो यह तय करती है कि फाइलों में जाँच के साथ कोई अंतर है या नहीं, रिवर्स रूपांतरण करता है तुलना करने से पहले , जिसके परिणामस्वरूप यह सोचता है कि रिपॉजिटरी में अनपेक्षित CRLF के साथ चेक आउट फ़ाइल में एक LF है।

जहाँ तक मैं देख सकता हूँ आपकी पसंद हैं:

1. Git-svn का उपयोग किए बिना अपने कोड को एक नए git रिपॉजिटरी में पुन: आयात करें, इसका मतलब यह होगा कि लाइन एंडिंग्स intial git कमिट में बदल दिए गए हैं- all
2. ऑटोक्रॉफ़्ट को झूठे पर सेट करें, और इस तथ्य को अनदेखा करें कि लाइन अंत गिट की पसंदीदा शैली में नहीं है
3. अपनी फ़ाइलों को आटोक्रॉफ्ट ऑफ के साथ देखें, सभी लाइन अंत को ठीक करें, वापस सब कुछ जांचें और इसे फिर से चालू करें।
4. अपने रिपॉजिटरी के इतिहास को फिर से लिखें ताकि मूल कमिट में अब CRLF न हो जिसमें उम्मीद नहीं थी। (इतिहास पुनर्लेखन के बारे में सामान्य जानकारी लागू होती है)

---

फुटनोट: यदि आप विकल्प # 2 चुनते हैं तो मेरा अनुभव यह है कि कुछ सहायक उपकरण (रिबास, पैच आदि) CRLF फ़ाइलों के साथ सामना नहीं करते हैं और आप CRLF और LF (असंगत लाइन) के मिश्रण के साथ फ़ाइलों को जल्दी या बाद में समाप्त करेंगे अंत)। मुझे पता है कि दोनों के सर्वश्रेष्ठ होने का कोई तरीका नहीं है।

Comments

मुझे लगता है कि आपकी सूची में जोड़ने के लिए एक 4 वां विकल्प है, यह मानते हुए कि कोई भी इतिहास को फिर से लिखने के लिए खर्च कर सकता है: आप एक git रेपो ले सकते हैं जिसे आपने शुरू में git-svn के साथ बनाया था, और इसके इतिहास को फिर से CRLF लाइनफ़ीड नहीं है। यह आपको आपके पूरे svn इतिहास के माध्यम से पीछे की ओर फैले सामान्यीकृत लाइनफीड्स देगा। उपयोगकर्ता keo stackoverflow.com/a/1060828/64257 पर एक समाधान प्रस्तुत करता है ।

— क्रिस

आपके फुटनोट के बारे में: rebaseCRLF के साथ कोई समस्या नहीं है। एकमात्र समस्या जो मुझे पता है वह यह है कि मानक git मर्ज टूल अपने संघर्ष चिह्नों ("<<<<<<<", ">>>>>>" आदि) को LF के साथ ही सम्मिलित करेगा, इसलिए संघर्ष मार्करों के साथ एक फ़ाइल होगी मिश्रित लाइन अंत है। हालांकि, एक बार जब आप मार्करों को हटा देते हैं, तो सब कुछ ठीक है।

— sleske

यह संभव है कि पिछले 3 वर्षों में गिट की हैंडलिंग बदल गई है, यह उस समय के साथ मेरा प्रत्यक्ष अनुभव था, मुझे इस विशेष मुद्दे को फिर से जारी करने की आवश्यकता नहीं है। YMMV।

— टिम अबेल

@sleske शुरू करने वाला git 2.8, मर्ज मार्कर अब मिश्रित लाइन एंडिंग का परिचय नहीं देगा । देखें stackoverflow.com/a/35474954/6309

— VonC

@VonC: यह अच्छा है। मुझे विंडोज पर काम करने की आवश्यकता के समय के लिए जानना अच्छा है।

— sleske

Answer 10

नीचे ~ / .gitattributes फ़ाइल से निकाल रहा है

* text=auto

पहली जगह में लाइन-एंडिंग को चेक करने से रोकेंगे।

Comments

गलत। यदि वह लाइन मौजूद है, तो core.autocrlf के कॉन्फ़िगरेशन को ओवरराइड कर देगा। अगर वह 'सही' पर सेट है, तो नहीं, उस लाइन को हटाने से गिट को लाइन एंडिंग की जाँच करने से रोका नहीं जाएगा।

— अरफांगियन

फिर भी, अगर core.autocrlf को सेट किया जाता है false, अगर इसे हटा नहीं दिया जाता है, तो autocrlf को झूठी स्थापित करने से बहुत मदद नहीं मिलेगी, इसलिए इसने मेरी मदद की (लेकिन यह अपने आप में पर्याप्त नहीं है)।

— मैटी

इस पर उपकार !! जबकि "तकनीकी रूप से सही नहीं है," जाँच से रोक देगा "यह केवल एक उत्तर है जो विशेष रूप से सभी text=में सेटिंग का उल्लेख करता है .gitattributes(जो, यदि मौजूद है, तो अवरोधक होगा)। अतः अन्य उत्तर अधूरे हैं। मैं पागल होने की कोशिश कर रहा था कि मेरी फाइलें "संशोधित" के रूप में क्यों दिखाई देती रहीं, चाहे कितनी भी बार मैंने अपना autocrlfऔर safecrlfसेटिंग्स बदल दिया और जीआईटी कैश और हार्ड रीसेट की जांच की और साफ कर दिया।

— jdunk

Answer 11

इसे पढ़ना चाहिए:

चेतावनी: ( यदि आप इसकी जाँच करते हैं / या अपने मौजूदा कोर के साथ किसी अन्य फ़ोल्डर में क्लोन करते हैं। डिपोफ्लोर होने के नातेtrue ,) LF को CRLF द्वारा बदल दिया जाएगा

फ़ाइल में आपकी ( वर्तमान ) कार्यशील निर्देशिका में इसकी मूल पंक्ति अंत होगी ।

इस चित्र को यह बताना चाहिए कि इसका क्या अर्थ है।

Comments

इसका अर्थ यह भी है कि जो तोड़फोड़ करने के लिए भेजा जाता है (यदि आप ऐसा करते हैं) रूपांतरण होगा।

— jpaugh

Answer 12

http://www.rtuin.nl/2013/02/how-to-make-git-ignore-different-line-endings/

echo "* -crlf" > .gitattributes 

एक अलग कमिट पर ऐसा करें या git अभी भी पूरी फ़ाइलों को संशोधित कर सकता है जब आप एक एकल परिवर्तन करते हैं (इस पर निर्भर करता है कि आपने ऑटोलोफ़र ​​विकल्प बदला है):

यह वास्तव में काम करता है। गिट मिश्रित लाइन एंडिंग परियोजनाओं में लाइन एंडिंग का सम्मान करेंगे और आपको उनके बारे में चेतावनी नहीं देंगे।

Comments

यह विशेष रूप से तब उपयोगी होता है जब आप CRLF और LF के बीच कनवर्ट करना चाहते हैं, लेकिन आपके पास कुछ .sh फाइलें होती हैं, जिन्हें बरकरार रहना चाहिए। मैं *.sh -crlfहर समय उपयोग करता हूं ...

— मार्टिनटेगा

Answer 13

मैं विंडोज पर गिट के बारे में ज्यादा नहीं जानता, लेकिन ...

मुझे लगता है कि git रनिंग प्लेटफॉर्म (विंडोज) के मिलान के लिए रिटर्न फॉर्मेट को परिवर्तित कर रहा है। CRLF विंडोज में डिफ़ॉल्ट रिटर्न फॉर्मेट है, जबकि LF अधिकांश अन्य OSes के लिए डिफ़ॉल्ट रिटर्न फॉर्मेट है।

संभावना है, कोड को किसी अन्य सिस्टम में ले जाने पर रिटर्न फॉर्मेट ठीक से समायोजित हो जाएगा। मैं यह भी मानता हूं कि जेपीईजी को CRLF में LFs में बदलने की कोशिश करने के बजाय बाइनरी फ़ाइलों को बरकरार रखने के लिए पर्याप्त स्मार्ट है।

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

परिशिष्ट: CR ASCII कोड 13 है, LF ASCII कोड 10 है। इस प्रकार, CRLF दो बाइट्स है, जबकि LF एक है।

Comments

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

— 1325

Answer 14

सुनिश्चित करें कि आपने नवीनतम गिट स्थापित किया है।
मैंने ऊपर जैसा किया git config core.autocrlf false, जब गिट (संस्करण 2.7.1) का उपयोग किया, लेकिन यह काम नहीं किया।
फिर यह काम करता है जब अपग्रेड गिट (2.7.1 से 2.20.1 तक)।

Comments

मुझे लगता है कि आपका मतलब है कि आपके पास 2.17.1 है। मैं एक ही मुद्दा रहा था और अद्यतन किया और यह भी इसे ठीक कर दिया। खुशी है कि मैंने आपका जवाब देखा!

— फिलिप मैकमुलेन

Answer 15

1. फ़ाइल को नोटपैड ++ में खोलें।
2. एडिट / ईओएल रूपांतरण पर जाएं।
3. विंडोज फॉर्मेट पर क्लिक करें।
4. फ़ाइल सहेजें।

Comments

इसके अलावा git config --global core.autocrlf falseGit को Unixकमिट करने के लिए लाइन एंडिंग को रोकने के लिए उपयोग करने का प्रयास करें। git config core.autocrlfवास्तव में गलत पर सेट है यह जांचने के लिए फॉलो अप करें ।

— कंटैंगो

Answer 16

OP का प्रश्न विंडोज़ से संबंधित है और मैं निर्देशिका में जाने या Notepad ++ में फ़ाइल चलाने के बिना दूसरों का उपयोग नहीं कर सका क्योंकि व्यवस्थापक ने काम नहीं किया .. इसलिए इस मार्ग पर जाना पड़ा:

C:\Program Files (x86)\Git\etc>git config --global core.autocrlf false

Answer 17

कई टेक्स्ट-एडिटर आपको LFनीचे बदलने की अनुमति देते हैं , नीचे एटम निर्देश देखें। सरल और स्पष्ट।

---

CRLFनीचे दाईं ओर क्लिक करें :

LFशीर्ष पर ड्रॉपडाउन में चुनें :

Answer 18

GNU / Linux शेल प्रॉम्प्ट में, dos2unix और unix2dos कमांड आपको MS Windows से आने वाली आपकी फ़ाइलों को आसानी से परिवर्तित / स्वरूपित करने की अनुमति देते हैं।

Answer 19

CRLF दो अलग-अलग OS (Linux और Windows) में आपके "कोड" का उपयोग करते समय कुछ समस्या पैदा कर सकता है। मेरी पाइथन लिपि को लिनक्स डॉकटर कंटेनर में लिखा गया था और फिर विंडोज गिट-बैश का उपयोग करके धक्का दिया गया था। इसने मुझे चेतावनी दी कि LF को CRLF द्वारा प्रतिस्थापित किया जाएगा। मैंने इसे बहुत सोचा नहीं था, लेकिन फिर जब मैंने बाद में स्क्रिप्ट शुरू की, तो यह कहा /usr/bin/env: 'python\r': No such file or directory। अब है कि \rआप के लिए ramification के लिए। विंडोज "CR" - गाड़ी वापसी - का उपयोग नई लाइन वर्ण के रूप में '\ n' के शीर्ष पर करता है \n\r। यह कुछ ऐसा है जिस पर आपको विचार करना पड़ सकता है।

Answer 20

विंडोज के अधिकांश टूल टेक्स्ट फ़ाइलों में केवल LF को स्वीकार करते हैं। उदाहरण के लिए आप निम्न सामग्री (भाग) के साथ '.editorconfig' नामक फ़ाइल में विज़ुअल स्टूडियो के व्यवहार को नियंत्रित कर सकते हैं:

 indent_style = space
 indent_size = 2
 end_of_line = lf    <<====
 charset = utf-8

केवल मूल विंडोज-नोटपैड एलएफ के साथ काम नहीं करता है, लेकिन कुछ और सरल संपादक उपलब्ध हैं!

इसलिए मुझे विंडोज में पाठ फ़ाइलों में एलएफ का उपयोग करना चाहिए। यह मेरा संदेश है, stronlgy की सिफारिश की! विंडोज़ में CRLF का उपयोग करने का कोई कारण नहीं है!

(सी / ++ में शामिल पथों में एक ही चर्चा \ n का उपयोग कर रहा है, यह बकवास है, स्लैश के साथ #include <pathTo / myheader.h> का उपयोग करें! यह C / ++ मानक है और सभी Microsoft कंपाइलर इसका उपयोग करते हैं)।

इसलिए git के लिए उचित सेटिंग है

git config core.autocrlf false

मेरा संदेश: ऐसे पुराने सोच कार्यक्रमों को dos2unix और unix2dos के रूप में भूल जाओ। अपनी टीम में स्पष्ट करें कि विंडोज के तहत एलएफ का उपयोग करना उचित है।