g-diff ^ ^ को अनदेखा करना

Question

एक ऐसी परियोजना में जहाँ कुछ फाइलों में ^ M न्यूलाइन विभाजक के रूप में होता है। इन फाइलों को मुश्किल से देखना असंभव है, क्योंकि git-diff इसे देखता है क्योंकि पूरी फाइल सिर्फ एक लाइन है।

पिछले संस्करण के साथ कोई कैसे भिन्न होता है?

क्या "उपचार ^ एम जब न्यूलाइन के रूप में अलग हो रहा है" जैसा कोई विकल्प है?

prompt> git-diff "HEAD^" -- MyFile.as 
diff --git a/myproject/MyFile.as b/myproject/MyFile.as
index be78321..a393ba3 100644
--- a/myproject/MyFile.cpp
+++ b/myproject/MyFile.cpp
@@ -1 +1 @@
-<U+FEFF>import flash.events.MouseEvent;^Mimport mx.controls.*;^Mimport mx.utils.Delegate
\ No newline at end of file
+<U+FEFF>import flash.events.MouseEvent;^Mimport mx.controls.*;^Mimport mx.utils.Delegate
\ No newline at end of file
prompt>

---

अपडेट करें:

अब मैंने एक रूबी स्क्रिप्ट लिखी है जो नवीनतम 10 संशोधनों की जांच करती है और सीआर को एलएफ में परिवर्तित करती है।

require 'fileutils'

if ARGV.size != 3
  puts "a git-path must be provided"
  puts "a filename must be provided"
  puts "a result-dir must be provided"
  puts "example:"
  puts "ruby gitcrdiff.rb project/dir1/dir2/dir3/ SomeFile.cpp tmp_somefile"
  exit(1)
end

gitpath = ARGV[0]
filename = ARGV[1]
resultdir = ARGV[2]

unless FileTest.exist?(".git")
  puts "this command must be run in the same dir as where .git resides"
  exit(1)
end

if FileTest.exist?(resultdir)
  puts "the result dir must not exist"
  exit(1)
end
FileUtils.mkdir(resultdir)

10.times do |i|
  revision = "^" * i
  cmd = "git show HEAD#{revision}:#{gitpath}#{filename} | tr '\\r' '\\n' > #{resultdir}/#{filename}_rev#{i}"
  puts cmd 
  system cmd
end

Comments

आप चाहते हो सकता है git diff -b- मैंने इसे stackoverflow.com/a/46265081/58794

— जेसन पीरोन

Git 2.16 (Q1 2018) के साथ, आपके पास होगा git diff --ignore-cr-at-eol। देखें नीचे मेरा उत्तर ।

— VonC

@ जैसनपायरन और भविष्य के Googlers के लिए: मुझे यह देखना था कि git diff -bयह समान है git diff --ignore-space-change।

— गोगोविट्च

Answer 1

GitHub सुझाव देता है कि आपको git-handled repos में newline वर्ण के रूप में only \ n का उपयोग करना चाहिए। ऑटो-कन्वर्ट करने का विकल्प है:

$ git config --global core.autocrlf true

बेशक, यह कहा जाता है कि crf को lf में बदलना है, जबकि आप cr को lf में बदलना चाहते हैं। मुझे उम्मीद है कि यह अभी भी काम करता है ...

और फिर अपनी फ़ाइलों को परिवर्तित करें:

# Remove everything from the index
$ git rm --cached -r .

# Re-add all the deleted files to the index
# You should get lots of messages like: "warning: CRLF will be replaced by LF in <file>."
$ git diff --cached --name-only -z | xargs -0 git add

# Commit
$ git commit -m "Fix CRLF"

core.autocrlf का वर्णन मैन पेज पर किया गया है ।

Comments

नहीं, निश्चित रूप से, एक बार सेटिंग होने के बाद, यह चुपचाप प्रतिबद्ध होने पर परिवर्तित हो जाएगा। अगर सब कुछ मेरे सोचने के तरीके से काम करता है, तो वह है ...

— nes1983

समस्या यह है कि मेरे पास पहले से ही रिपॉजिटरी में कुछ फाइलें हैं जिनमें CRLF एंडिंग्स हैं और अन्य जो नहीं हैं। मुझे संदेह है कि Adobe Flash मैक संस्करण का उपयोग करने के बावजूद CRLF जोड़ता है। मुझे इन फ़ाइलों के पुराने संशोधनों के खिलाफ तुलना करने की आवश्यकता है। अब से शुरू होने वाली लाइन एंडिंग को पुराने संशोधनों के साथ समस्या हल नहीं होती है: - /

— neoneye

आप यहां CRLF फ़ाइलों के साथ काम नहीं कर रहे हैं, कम से कम आपके द्वारा पोस्ट किए गए उदाहरण में नहीं। यह एक पुरानी शैली की मैक फ़ाइल है (केवल EOL के लिए \ r का उपयोग करता है)। इसीलिए एक लाइन पर अंतर दिखाया जा रहा है। डॉस ईओएल का उपयोग करने वाली एक फ़ाइल प्रत्येक पंक्ति को एक अनुगामी ^ एम के साथ अलग-अलग दिखाएगी, जिसे आप बता सकते हैं कि आपको किसके माध्यम से संभालना है git config core.whitespace cr-at-eol।

— जैमेसन 19

मैं यह कोशिश कर रहा हूं, लेकिन मैं warning: LF will be replaced by CRLFइसके बजाय मिलता warning: CRLF will be replaced by LFरहा हूं, और मैं लिनक्स में हूं। कोई विचार क्यों? मैं चाहता हूं कि सभी एलएफ के साथ समाप्त हो जाएं, न कि सीआरएलएफ!

— trusktr

@trusktr, मेरे साथ भी ऐसा ही हुआ। लिनक्स में, आकस्मिक CRLF के साथ, उपयोग git config --global core.autocrlf inputकरें, इस उत्तर में चरण (rm, ऐड, कमिट) करें, और आपको मिलेगा warning: CRLF will be replaced by LF. The file will have its original line endings in your working directory.। फ़ाइलों को निकालें (क्योंकि उनके पास मूल, गलत CRLF है) और अंतिम "CRLF" प्रतिबद्ध से उन्हें फिर से चेकआउट करें।

— जम्मु

Answer 2

विंडोज पर विकसित करना, उपयोग करते समय मैं इस समस्या में भाग गया git tfs। मैंने इसे इस तरह हल किया:

git config --global core.whitespace cr-at-eol

यह मूल रूप से गिट को बताता है कि एक अंत-पंक्ति सीआर एक त्रुटि नहीं है। नतीजतन, उन कष्टप्रद ^Mपात्रों अब में लाइनों के अंत में प्रदर्शित git diff, git showआदि

यह अन्य सेटिंग्स को छोड़ देता है जैसा कि है; उदाहरण के लिए, एक पंक्ति के अंत में अतिरिक्त स्थान अभी भी त्रुटियों (लाल रंग में हाइलाइट किए गए) के रूप में दिखाई देते हैं।

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

संपादित करें :

कई लाइन-एंड ट्रैवेल्स के बाद, इन सेटिंग्स के साथ, .NET टीम पर काम करते समय मुझे सबसे अच्छी किस्मत मिली है:

• कोई core.eol सेटिंग
• कोई core.whitespace सेटिंग
• कोई core.autocrlf सेटिंग
• Windows के लिए Git इंस्टॉलर चलाते समय, आपको ये तीन विकल्प मिलेंगे:
  • चेकआउट विंडोज-स्टाइल, कमिटिक्स यूनिक्स-स्टाइल लाइन एंडिंग्स <- यह चुनें
  • चेकआउट के रूप में, यूनिक्स शैली लाइन अंत प्रतिबद्ध है
  • के रूप में चेकआउट है, के रूप में प्रतिबद्ध है

यदि आपको व्हाट्सएप सेटिंग का उपयोग करने की आवश्यकता है, तो शायद आपको इसे केवल प्रति-प्रोजेक्ट के आधार पर सक्षम करना चाहिए यदि आपको टीएफएस के साथ बातचीत करने की आवश्यकता है। बस छोड़ दें --global:

git config core.whitespace cr-at-eol

यदि आपको कुछ कोर निकालने की आवश्यकता है। * सेटिंग्स, इस कमांड को चलाने का सबसे आसान तरीका है:

git config --global -e

यह एक पाठ संपादक में आपकी वैश्विक .gitconfig फ़ाइल को खोलता है, और आप आसानी से उन पंक्तियों को हटा सकते हैं जिन्हें आप निकालना चाहते हैं। (या आप उन्हें टिप्पणी करने के लिए उनके सामने '#' रख सकते हैं।)

Comments

जिन लोगों को यह अब मिल रहा है, उनके लिए यह ध्यान देने योग्य है कि चेकआउट विंडोज-स्टाइल, यूनिक्स-स्टाइल लाइन को ऑटो-सेट्स के core.autocrlfलिए प्रतिबद्ध करता हैtrue

— । कारपेंटर

ध्यान दें कि लाइन git config --global core.whitespace cr-at-eolअन्य सेटिंग्स को बंद कर देगी जो डिफ़ॉल्ट हैं। तीन डिफॉल्ट हैं: खाली-एट-एओल, खाली-एट-एओफ़ और स्पेस-पहले-टैब। तो करोड़-एट-EOL जबकि दूसरों को आप का उपयोग करने की आवश्यकता होगी रखने सक्षम करने के लिए git config --global core.whitespace blank-at-eol,blank-at-eof,space-before-tab,cr-at-eol।

— Zitrax

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

— जानिस एल्मेरिस

SourceInsight ^ M कैरेक्टर को आगे बढ़ाती है और git अभी भी लाइन एंडिंग में अंतर दिखाता है। @ Zitrax की कमांड मेरे मामले का सही उत्तर है, git काफी अच्छा और साफ आउटपुट दिखाती है।

— Lê Quang Duy

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

— रॉल्फ

Answer 3

कोशिश करो git diff --ignore-space-at-eol, या git diff --ignore-space-change, या git diff --ignore-all-space।

Comments

वास्तव में कोई भी उस चरित्र को प्रभावित नहीं करता है जो नई रेखा की पहचान करता है।

— nes1983

मैंने "-w" के साथ भी कोशिश की, लेकिन कोई भाग्य नहीं है, फिर भी इसे एक पंक्ति के रूप में मानता है। अगली परियोजना मुझे कभी भी किसी भी सीआर को स्रोत कोड में लाने के लिए याद रखना चाहिए।

— नवनीत

बस git config को याद रखें - global core.autocrlf true, या git people को तब तक बग करें जब तक वे इसे डिफ़ॉल्ट न बना दें

— nes1983

इसने मेरी autocrlfसेटिंग को बदलने के बिना मेरी समस्या को हल किया । धन्यवाद!

— nnonneo

इन झंडों का मेरे ऊपर कोई प्रभाव नहीं है ... फिर भी ^ M as diffs

— Magnus

Answer 4

और देखें:

core.whitespace = cr-at-eol

या समकक्ष,

[core]
    whitespace = cr-at-eol

जहां whitespaceएक टैब चरित्र से पहले है ।

Comments

हां, इसने गिट डिफ टूल बनाया (जिसका इस्तेमाल भी किया गया था git show) ने मुझे ^Mबदली हुई रेखाओं के बारे में बताने से रोक दिया! :)

— रिज्क

जो भी कारण यह मेरे लिए काम नहीं किया। इसे = और नहीं = चिन्ह दोनों के साथ आज़माया। git diffअभी भी ^ M अक्षर दिखाता है।

— डेनिस

इसे करने के दो तरीके: एक, अपने .bitconfig में .bit / config, या ~ / .gitconfig में वर्बेटिम के ऊपर की रेखा जोड़ें; दो, git config --global core.whitespace cr-at-eol(जहां -ग्लोबल वैकल्पिक है यदि आप इसे केवल रेपो पर चाहते हैं)

— । कारपेंटर

यह मेरे लिए विंडोज 7 पर काम करता है, हालांकि मैंने इसे अभी के तहत रखा है [core]ताकि मैं core.उपसर्ग को एक टैब चरित्र के साथ बदल सकूं।

— रफ़लविंड

यह सवाल कैसे छिपाने के लिए ऊपर था ^Mमें git diff, के बारे में नहीं पहली जगह में में ^ एम नहीं डाल करने के लिए कैसे। इसका मतलब है कि बदलने core.autocrlfका स्वीकृत उत्तर सबसे अच्छा नहीं है क्योंकि यह उपयोगकर्ता की पुष्टि के बिना फ़ाइलों को चुपचाप बदल देता है।

— deddebme

Answer 5

क्यों आप इन मिलता है ^Mअपने में git diff?

मेरे मामले में मैं एक ऐसी परियोजना पर काम कर रहा था जो विंडोज़ में विकसित की गई थी और मैंने ओएस एक्स का इस्तेमाल किया था। जब मैंने कुछ कोड बदले, तो मैंने ^Mउन लाइनों के अंत में देखा , जिन्हें मैंने जोड़ा था git diff। मुझे लगता है कि ^Mवे दिखा रहे थे क्योंकि वे फ़ाइल के बाकी हिस्सों की तुलना में अलग लाइन अंत थे। क्योंकि शेष फ़ाइल को विंडोज में विकसित किया गया था जिसमें यह CRलाइन एंडिंग का उपयोग करता LFथा , और ओएस एक्स में यह लाइन एंडिंग का उपयोग करता है।

जाहिरा तौर पर, विंडोज डेवलपर ने गिट की स्थापना के दौरान " चेकआउट विंडोज-स्टाइल, कमिटिक्स यूनिक्स-स्टाइल लाइन एंडिंग्स " विकल्प का उपयोग नहीं किया ।

तो हमें इस बारे में क्या करना चाहिए?

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

यदि आप इस विकल्प के लिए जाते हैं, तो आपको हालांकि वर्तमान फ़ाइलों को ठीक करना चाहिए (क्योंकि वे अभी भी CRलाइन एंडिंग का उपयोग कर रहे हैं)। मैंने इन चरणों का पालन करके ऐसा किया है:

1. रिपॉजिटरी से सभी फाइलें निकालें, लेकिन आपके फाइल सिस्टम से नहीं।

   git rm --cached -r .
   

2. एक ऐसी .gitattributesफ़ाइल जोड़ें जो एक LFपंक्ति के अंत का उपयोग करने के लिए कुछ फ़ाइलों को लागू करती है। इसे फ़ाइल में रखें:

   *.ext text eol=crlf
   

   .extउस फ़ाइल एक्सटेंशन से बदलें जिसे आप मिलान करना चाहते हैं।

3. फिर से सभी फाइलें जोड़ें।

   git add .
   

   यह इस तरह संदेश दिखाएगा:

   warning: CRLF will be replaced by LF in <filename>.
   The file will have its original line endings in your working directory.
   

4. आप .gitattributesफ़ाइल को तब तक निकाल सकते हैं जब तक कि आपके पास विंडोज उपयोगकर्ता नहीं हैं जो " चेकआउट विंडोज-स्टाइल, कमिटमेंट यूनिक्स-स्टाइल लाइन एंडिंग्स " विकल्प का उपयोग नहीं करना चाहते हैं ।

5. प्रतिबद्ध और यह सब धक्का।

6. उन सभी सिस्टमों पर लागू फ़ाइलों को निकालें और चेकआउट करें जहाँ उनका उपयोग किया जाता है। विंडोज सिस्टम पर, सुनिश्चित करें कि वे अब " चेकआउट विंडोज-स्टाइल, कमिट-यूनिक्स-स्टाइल लाइन एंडिंग्स " विकल्प का उपयोग करते हैं। आपको यह उस सिस्टम पर भी करना चाहिए जहां आपने इन कार्यों को अंजाम दिया क्योंकि जब आपने फाइलें जोड़ीं तो git ने कहा:

   The file will have its original line endings in your working directory.
   

   फ़ाइलों को निकालने के लिए आप ऐसा कुछ कर सकते हैं:

   git ls | grep ".ext$" | xargs rm -f
   

   और फिर उन्हें सही लाइन एंडिंग के साथ वापस लाने के लिए:

   git ls | grep ".ext$" | xargs git checkout
   

   बेशक .extआप चाहते हैं कि विस्तार के साथ की जगह ।

अब आपका प्रोजेक्ट केवल LFलाइन एंडिंग के लिए वर्णों का उपयोग करता है, और गंदा CRअक्षर कभी वापस नहीं आएगा :)।

दूसरा विकल्प विंडोज़ स्टाइल लाइन एंडिंग्स लागू करना है। इसके लिए आप .gitattributesफाइल का भी इस्तेमाल कर सकते हैं ।

अधिक जानकारी: https://help.github.com/articles/dealing-with-line-endings/#platform-

Comments

किसी विशिष्ट फ़ाइल में सभी पंक्ति अंत को ठीक करने के लिए, यदि उदात्त पाठ का उपयोग करते हुए, आप View-> Line Endingsपर जा सकते हैं और क्लिक कर सकते हैं Unix।

— टोपेर हंट

इसका वास्तव में क्या ^Mमतलब है? यह एक विंडोज़ या लिनक्स न्यूलाइन है? या यह फ़ाइल में अन्य newlines की तुलना में सिर्फ एक "अलग" न्यूलाइन है?

— buhtz

अच्छा है, मुझे लगता है कि यह सिर्फ एक "अलग" नई लाइन (सबसे अलग है)

— गीताकार

-1 के रूप में पूरा करने के लिए git को फिर से भरना git config --global core.autocrlf trueओवरकिल है, और एंटी-विंडोज / एंटी- CRअभियान इस प्रश्न के लिए महत्वपूर्ण है।

— RJFalconer

Answer 6

क्या "उपचार ^ एम जब न्यूलाइन के रूप में अलग हो रहा है" जैसा कोई विकल्प है?

Git 2.16 (Q1 2018) के साथ एक होगा, क्योंकि " diff" कमांड के परिवार ने लाइन के अंत में गाड़ी वापसी में अंतर को अनदेखा करना सीखा।

देखें e9282f0 प्रतिबद्ध (26 अक्टू 2017) द्वारा Junio सी Hamano ( gitster) ।
मदद-द्वारा: जोहान्स शिंडलिन ( dscho) ।
^{( जूनियो सी gitsterहमानो द्वारा विलय - - 10f65c2 , 27 नवंबर 2017 को प्रतिबद्ध )}

diff: --ignore-cr-at-eol

एक नया विकल्प --ignore-cr-at-eolएक (पूर्ण) लाइन के अंत में एक कैरिज-रिटर्न का इलाज करने के लिए अलग मशीनरी बताता है जैसे कि यह मौजूद नहीं है।

--ignore-*विभिन्न प्रकार के व्हाट्सएप मतभेदों को नजरअंदाज करने के लिए अन्य " " विकल्पों की तरह , यह CRLF<->LFआपके संपादक कार्यक्रम द्वारा किए गए शानदार रूपांतरण से विचलित हुए बिना आपके द्वारा किए गए वास्तविक परिवर्तनों की समीक्षा करने में मदद करेगा ।

Comments

@kaartic उत्तर को संपादित करने और सही वचन का संदर्भ देने के लिए धन्यवाद!

— वॉनसी

जब भी यह आम तौर पर git config --global core.autocrlf trueस्वीकार किए गए उत्तर के रूप में सेट करने के लिए अच्छा अभ्यास होता है , तो यह ओपी के प्रश्न का अधिक सीधे उत्तर देता है: 'क्या "विकल्प ^ एम के रूप में न्यूलाइन के रूप में अलग होने पर" एक विकल्प है?'

— 5

Git 2.20 के अनुसार यह ^ M

— user1944491

@ user1944491 मैंने किसी प्रतिगमन पर ध्यान नहीं दिया, जिसका अर्थ यह है कि गिल 2.26 में इस विकल्प के साथ अलग होने पर ईओल की अनदेखी करता है।

— VonC

@VonC इस तर्क का प्रयोग git diff कमांड में काम नहीं किया। और न ही मेरे core.whitespace मान की स्थापना की, git version 2.20.1 (Apple Git-117)लेकिन जेसन Pyeron के core.pager उत्तर को जोड़कर इसे ठीक कर दिया। YMMV जाहिर है।

— 14:19 पर user1944491

Answer 7

टी एल; डॉ

स्रोत कोड को नहीं, core.pagerको बदलें"tr -d '\r' | less -REX"

इसलिए

उन pesky ^ M को दिखाया गया है कि वे रंगकरण और पेजर की एक कलाकृति हैं। यह less -Rडिफ़ॉल्ट डिफ़ॉल्ट पेजर विकल्प के कारण होता है । (git का डिफ़ॉल्ट पेजर है less -REX)

ध्यान देने वाली पहली बात यह है कि git diff -bसफेद स्थान में परिवर्तन नहीं दिखाई देंगे (जैसे \ r \ n बनाम \ n)

सेट अप:

git clone https://github.com/CipherShed/CipherShed
cd CipherShed

एक यूनिक्स फ़ाइल बनाने और लाइन एंडिंग बदलने के लिए एक त्वरित परीक्षण इसके साथ कोई बदलाव नहीं दिखाएगा git diff -b:

echo -e 'The quick brown fox\njumped over the lazy\ndogs.' > test.txt
git add test.txt
unix2dos.exe test.txt
git diff -b test.txt

हम ध्यान दें कि पाइप को कम करने के लिए ^ M नहीं दिखाता है, लेकिन रंग को सक्षम less -Rकरता है और करता है:

git diff origin/v0.7.4.0 origin/v0.7.4.1 | less
git -c color.ui=always diff origin/v0.7.4.0 origin/v0.7.4.1 | less -R

फिक्स को आउटपुट से \ r (^ M) स्ट्रिप करने के लिए एक पाइप का उपयोग करके दिखाया गया है:

git diff origin/v0.7.4.0 origin/v0.7.4.1
git -c core.pager="tr -d '\r' | less -REX"  diff origin/v0.7.4.0 origin/v0.7.4.1

एक नासमझ विकल्प का उपयोग करना है less -r, क्योंकि यह सभी नियंत्रण कोडों से होकर गुजरेगा, न कि केवल रंग कोडों के माध्यम से।

यदि आप अपनी git config फाइल को सीधे संपादित करना चाहते हैं, तो यह अपडेट / जोड़ने की प्रविष्टि है:

[core]
        pager = tr -d '\\r' | less -REX

Comments

मुझे रेपो में यह समस्या थी जहाँ कुछ फाइलों में \r\nलाइन एंडिंग थी और कुछ में \nलाइन एंडिंग थी (मुझे नहीं पता कि यह प्रासंगिक है); पूर्व के रूपांतरों को ^Mसंशोधित रेखाओं में दिखाया गया है (अर्थात, +रेखाएँ)। core.autocrlfके लिए सेट किया गया था true। रनिंग git config core.pager "tr -d '\r' | less -REX"ने पेसकी ^Mएस से छुटकारा पा लिया । धन्यवाद!

— Labreuer

इसके लिए धन्यवाद। यह एकमात्र उत्तर है यदि आपको अपने रेपो (एस) में अलग-अलग लाइन अंत के साथ काम करना चाहिए - जैसे आप चेकआउट का उपयोग करते हैं-जैसा है, जैसा कि उद्देश्यपूर्ण है।

— माइक

git diff -bवह है जो मैं ढूंढ रहा था, लेकिन मैं पूरी तरह से स्पष्टीकरण की सराहना करता हूं।

— मार्टिन बर्च

यह जवाब है! धन्यवाद। -b झंडा मेरे लिए काम नहीं किया।

— क्रिस

हाँ! इस प्रश्न के सभी उत्तरों में से, "कॉन्फ़िगर" फ़ाइल के [core]अनुभाग को जोड़कर संशोधित करना pager = tr -d '\\r' | less -REXमेरे लिए काम करने वाला एकमात्र उत्तर था। धन्यवाद!

— राशिकी

Answer 8

मैं लंबे समय तक इस समस्या से जूझता रहा। अब तक का सबसे आसान उपाय है ^ M अक्षर के बारे में चिंता न करना और बस एक विजुअल डिफरेंशियल टूल का उपयोग करना जो उन्हें संभाल सके।

टाइप करने के बजाय:

git diff <commitHash> <filename>

प्रयत्न:

git difftool <commitHash> <filename>

Comments

धन्यवाद! इसके अलावा, मैंने सिर्फ "गिट डिफटूल" चलाया और यह मूल रूप से एक लूप में सभी परिवर्तित फ़ाइलों की तुलना में

— भानुप्रकाश डी

Answer 9

मेरे मामले में, यह किसने किया था:

git config  core.whitespace cr-at-eol

स्रोत: https://public-inbox.org/git/[e-mail]/T/

Answer 10

जैसा कि VonC द्वारा बताया गया है, इसे पहले ही git 2.16+ में शामिल किया जा चुका है। दुर्भाग्य से, विकल्प का नाम ( --ignore-cr-at-eol) GNU द्वारा उपयोग किए गए एक से भिन्न होता है, जिसका उपयोग मैं करने के लिए कर रहा हूँ (--strip-trailing-cr ) के ।

जब मुझे इस समस्या का सामना करना पड़ा, तो मेरा समाधान था कि जीएनयू को गिट के बिल्ट-इन फॉर्म के बजाय अलग करना होगा, क्योंकि मेरा गिट 2.16 से पुराना है। मैंने इस कमांड लाइन का उपयोग किया है:

GIT_EXTERNAL_DIFF='diff -u --strip-trailing-cr "$2" "$5";true;#' git diff --ext-diff

यह प्रयोग करने की अनुमति देता है --strip-trailing-crऔर किसी भी अन्य GNU विकल्प को अलग करता है।

इसका दूसरा तरीका भी है:

git difftool -y -x 'diff -u --strip-trailing-cr'

लेकिन यह कॉन्फ़िगर पेजर सेटिंग्स का उपयोग नहीं करता है, यही वजह है कि मैं पूर्व को पसंद करता हूं।

Comments

मेरे जवाब का दिलचस्प विकल्प। Upvoted।

— VonC