গিট-ডিফ উপেক্ষা করতে ^ এম

Question

এমন একটি প্রকল্পে যেখানে কিছু ফাইলের মধ্যে নিউ লাইন বিভাজক হিসাবে ^ এম থাকে। এই ফাইলগুলির মধ্যে পার্থক্য করা দৃশ্যত অসম্ভব, যেহেতু গিট-ডিফ এটি পুরো ফাইলটি কেবল একটি লাইন হিসাবে দেখায়।

আগের সংস্করণটির সাথে কীভাবে আলাদা হয়?

"ডিফারিং করার সময় treat এমকে নতুন লাইন হিসাবে ট্রিট করুন" এর মতো বিকল্প নেই?

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

— জেসন Pyeron

গিট 2.16 (Q1 2018) এর সাথে আপনার কাছে থাকবে git diff --ignore-cr-at-eol। দেখুন নিচের আমার উত্তর ।

— ভোনসি

@JasonPyeron এবং ভবিষ্যতে Googlers দের জন্য: আমি সন্ধান করতে যে ছিল git diff -bঅভিন্ন git diff --ignore-space-change।

— গোগোভিটশ

Answer 1

গিটহাব পরামর্শ দেয় যে গিট-হ্যান্ডলড রেপোগুলিতে আপনার কেবলমাত্র line n একটি নতুন লাইন চরিত্র হিসাবে ব্যবহার করা উচিত তা নিশ্চিত করা উচিত। স্বতঃ-রূপান্তর করার বিকল্প রয়েছে:

$ git config --global core.autocrlf true

অবশ্যই, এটি crlf কে 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 উপর বর্ণনা করা হয়েছে man পৃষ্ঠা ।

Comments

না, অবশ্যই না, একবার সেটিংটি হয়ে গেলে, এটি নিঃশব্দে প্রতিশ্রুতিবদ্ধ হয়ে রূপান্তরিত হবে। সবকিছু যদি মনে হয় যেভাবে কাজ করে তবে তা ...

— nes1983

সমস্যাটি হ'ল আমার কাছে ইতিমধ্যে ভান্ডারটিতে এমন কিছু ফাইল রয়েছে যার সিআরএলএফ সমাপ্তি রয়েছে এবং অন্যগুলি নেই। আমি সন্দেহ করি যে আমি ম্যাক সংস্করণটি ব্যবহার করছি তবুও অ্যাডোব ফ্ল্যাশ সিআরএলএফ যুক্ত করেছে। আমার এই ফাইলগুলির পুরানো সংশোধনগুলির সাথে তুলনা করতে হবে। এখন থেকে শুরু করে লাইন এন্ডে রূপান্তর করা পুরানো সংশোধনগুলি দিয়ে সমস্যার সমাধান করে না: - /

— নিউনি

আপনি এখানে সিআরএলএফ ফাইলগুলির সাথে কাজ করছেন না, কমপক্ষে আপনি পোস্ট করেছেন এমন উদাহরণে নয়। এটি একটি পুরানো স্টাইলের ম্যাক ফাইল (ইওএল এর জন্য কেবলমাত্র \ r ব্যবহার করে)। একারণে ভিন্নতা দেখানো হচ্ছে। ডস ইওএল ব্যবহার করে একটি ফাইল প্রতিটি লাইনকে একটি পিছনে ^ এম দিয়ে আলাদাভাবে প্রদর্শন করবে, যা আপনি হ্যান্ডেল পেতে বলবেন git config core.whitespace cr-at-eol।

— জামেসান

আমি এটি চেষ্টা করছি, তবে আমি warning: LF will be replaced by CRLFতার পরিবর্তে পেতে warning: CRLF will be replaced by LFথাকি এবং আমি লিনাক্সে আছি। কোন ধারণা কেন? আমি চাই সবগুলি এলএফ দিয়ে শেষ হোক, সিআরএলএফ নয়!

— trusktr

@ ট্রুসক্রিটার, আমার ক্ষেত্রেও একই ঘটনা ঘটেছিল। লিনাক্সে, দুর্ঘটনাজনক সিআরএলএফ সহ, git config --global core.autocrlf inputএই উত্তরের পদক্ষেপগুলি ব্যবহার করুন (আরএম, যোগ করুন, প্রতিশ্রুতি দিন) এবং আপনি পাবেন warning: CRLF will be replaced by LF. The file will have its original line endings in your working directory.। ফাইলগুলি সরান (কারণ তাদের আসল, ভুল সিআরএলএফ রয়েছে) এবং সর্বশেষ "ফিক্স সিআরএলএফ" কমিট থেকে তাদের আবার চেকআউট করুন।

— jmmut

Answer 2

উইন্ডোজের বিকাশ, ব্যবহার করার সময় আমি এই সমস্যায় পড়েছিলাম git tfs। আমি এটি এইভাবে সমাধান করেছি:

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

এটি মূলত গিটকে বলে যে একটি শেষের-লাইন সিআর ত্রুটি নয়। ফলস্বরূপ, সেই বিরক্তিকর ^Mঅক্ষর আর এ লাইনের শেষে প্রদর্শিত git diff, git showইত্যাদি

এটি অন্যান্য সেটিংসকে যেমন রয়েছে তেমন ছেড়ে যায় বলে মনে হয়; উদাহরণস্বরূপ, একটি লাইনের শেষে অতিরিক্ত স্পেসগুলি এখনও তফাতগুলিতে ত্রুটি হিসাবে দেখায় (লাল বর্ণিত)।

(অন্যান্য উত্তরগুলি এটিকে ইঙ্গিত করেছে, তবে উপরেরটি ঠিক কীভাবে সেটিংটি সেট করতে হবে only কেবলমাত্র একটি প্রকল্পের জন্য সেটিংস সেট করতে, বাদ দিন --global))

সম্পাদনা :

অনেকগুলি লাইন-এন্ডেন্ডিং ট্র্যাভেলের পরে, এই সেটিংগুলির সাথে একটি .NET টিমে কাজ করার সময় আমার খুব ভাল ভাগ্য হয়েছিল:

• কোন কোর.ইল সেটিং নেই
• কোন কোর.সাইটস স্পেস সেটিং
• কোন কোর.আউটোক্রল্ফ সেটিং নেই
• উইন্ডোজের জন্য গিট ইনস্টলার চালানোর সময়, আপনি এই তিনটি বিকল্প পাবেন:
  • উইন্ডোজ-শৈলীতে চেকআউট করুন, ইউনিক্স-স্টাইলের লাইনের সমাপ্তি কমিট করুন <- এটি চয়ন করুন
  • যেমন আছে তেমন চেকআউট করুন, ইউনিক্স-স্টাইলের লাইনের শেষটি করুন
  • চেকআউট যেমন রয়েছে তেমন প্রতিশ্রুতিবদ্ধ

আপনার যদি হোয়াইটস্পেস সেটিংটি ব্যবহার করতে হয়, আপনার যদি টিএফএসের সাথে ইন্টারঅ্যাক্ট করতে হয় তবে আপনার সম্ভবত প্রতি-প্রকল্পের ভিত্তিতে এটি সক্ষম করা উচিত। কেবল বাদ দিন --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ডিফল্ট অন্যান্য সেটিংস বন্ধ করে দেবে। তিনটি ডিফল্ট রয়েছে: ফাঁকা-এ-ইওল, ফাঁকা-এ-ইওফ এবং স্পেস-আগে-ট্যাব। তাই অন্যদের আপনার ব্যবহারের প্রয়োজন রাখার সময় cr-at-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 ight M অক্ষরটিকে চাপ দিচ্ছেন এবং গিটটি এখনও লাইন শেষের মধ্যে পার্থক্য দেখায়। @ জিট্রাসের কমান্ডটি আমার ক্ষেত্রে সঠিক উত্তর, গিট ডিফ শো এবং সুন্দর আউটপুট প্রদর্শন করে।

— Lê Quang Duy

আমি মনে করি গিটকে আরও কিছুটা জটিলতা দরকার, লাইনের শেষের জন্য আরও কয়েকটি বিরোধী সেটিংস। আমি মনে করি গিটটি আমার সাদা স্থান সম্পর্কে আরও বেশি চিন্তিত হওয়া উচিত । উদাহরণস্বরূপ, একটি সম্পর্কযুক্ত মারাত্মক ত্রুটি নিক্ষেপ করুন এবং উইন্ডোজ (তবে লিনাক্স নয়) মেশিনে ম্যাক লাইন শেষের মুখোমুখি হওয়ার সময় একটি দুর্নীতিগ্রস্থ অবস্থায় সংগ্রহস্থলটি রেখে দিন। আমি বোঝাতে চাইছি কেন আমি এমন কোনও ভিসিএস ব্যবহার করব যা এটির ব্যবসায়ের বিষয়টি মনে করবে এবং আমি যে লাইনের শেষটি চাই তা ব্যবহার করতে দেব? আমি দেখতে পাচ্ছি যে তারা চেষ্টা করছে, তবে অস্তিত্বহীন সমস্যা সমাধানের জন্য তাদের আরও অর্ধ ডজন লাইন-শেষের আচরণগুলি ছুঁড়ে ফেলা উচিত। তারা প্রায় সেখানে! এটা বজায় রাখা.

— রোল্ফ

Answer 3

চেষ্টা করুন git diff --ignore-space-at-eol, বা git diff --ignore-space-change, বা git diff --ignore-all-space।

Comments

এর কিছুই সত্যই নয় যে লাইনটি সনাক্ত করে এমন চরিত্রটিকে প্রভাবিত করে।

— nes1983

আমি "-w" দিয়েও চেষ্টা করেছি তবে ভাগ্য নেই, এখনও একে একক লাইন হিসাবে গণ্য করে। পরের প্রকল্পটি আমার অবশ্যই মনে রাখতে হবে কখনই উত্স কোডে কোনও সিআর না পাওয়া।

— নিউইনি

গিট কনফিগারেশন - গ্লোবাল কোর.আউটোক্রল্ফকে সত্য মনে রাখুন বা গিট লোকেরা এটিকে ডিফল্ট না করা পর্যন্ত বাগ করুন :)

— nes1983

এটি আমার autocrlfসেটিংস পরিবর্তন না করেই আমার সমস্যার সমাধান করেছে । ধন্যবাদ!

— নিনেনিও

এই পতাকাগুলি আমার জন্য কোনও প্রভাব ফেলেনি ... এখনও ^ এমকে আলাদা হিসাবে দেখায়

— ম্যাগনাস

Answer 4

আরও দেখুন:

core.whitespace = cr-at-eol

বা সমতুল্য,

[core]
    whitespace = cr-at-eol

যেখানে whitespaceতার আগে একটি ট্যাব চরিত্র রয়েছে।

Comments

হ্যাঁ, এটি গিট ডিফ সরঞ্জাম তৈরি করেছে (এছাড়াও এটি ব্যবহৃত হয়েছিল git show) ^Mপরিবর্তিত লাইনে এস সম্পর্কে আমাকে বগিং করা বন্ধ করে দেয়! :)

— রিজক

যে কারণেই এটি আমার পক্ষে কার্যকর হয়নি। এটিকে = এবং না = চিহ্ন দিয়ে উভয়ই চেষ্টা করেছেন। git diffএখনও ^ এম অক্ষর দেখায়।

— ডেনিস

এটি করার দুটি উপায়: একটি, .git / কনফিগারেশনে অথবা ~ / .gitconfig এ আপনার .gitconfig- এ ভার্ব্যাটিমের উপরের লাইনটি যুক্ত করুন; দুই, git config --global core.whitespace cr-at-eol(যেখানে - গ্লোবাল isচ্ছিক আপনি যদি এটি ঠিক আপনার রেপোতে চান তবে)

— কে। কার্পেন্টার

এটি আমার জন্য উইন্ডোজ on এ কাজ করেছে, যদিও আমি এটি কেবলমাত্র এটির অধীনে [core]রেখেছি তাই আমি core.টিএবি অক্ষরের সাথে উপসর্গটি প্রতিস্থাপন করতে পারি ।

— রাফলউইন্ড

এই প্রশ্নের কিভাবে লুকিয়ে রাখবেন তা উপরে ছিল ^Mমধ্যে git diffপ্রায় না প্রথম স্থানে মধ্যে ^ এম করা কিভাবে। তার মানে পরিবর্তনের স্বীকৃত উত্তরটি core.autocrlfসেরা নয় কারণ এটি ব্যবহারকারীর নিশ্চিতকরণ ছাড়াই নিঃশব্দে ফাইলগুলিকে পরিবর্তন করে।

— দেশদেবমে

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. সমস্ত সিস্টেমে প্রযোজ্য ফাইলগুলি সেগুলিতে ব্যবহৃত হয় এবং চেকআউট করুন। উইন্ডোজ সিস্টেমগুলিতে, নিশ্চিত হয়ে নিন যে তারা এখন " চেকআউট উইন্ডোজ-স্টাইল ব্যবহার করে , ইউনিক্স-স্টাইলের লাইন সমাপ্তি " বিকল্পটি ব্যবহার করে। আপনি যে সিস্টেমে এই কাজগুলি সম্পাদন করেছেন সেই সিস্টেমে আপনার এটি করা উচিত কারণ আপনি ফাইলগুলি যোগ করার সময় গিট বলেছিল:

   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-all

Comments

নির্দিষ্ট ফাইলটিতে সমস্ত লাইন শেষ ঠিক করতে, সাব্লাইম টেক্সট ব্যবহার করা হলে, আপনি View-> এ Line Endingsগিয়ে ক্লিক করতে পারেন Unix।

— টোফার হান্ট

এর ^Mঅর্থ কী? এটি একটি উইন্ডো বা লিনাক্স নতুন লাইন? বা ফাইলের অন্যান্য নতুন লাইনের তুলনায় এটি কেবল একটি "ভিন্ন" নিউলাইন?

— বুথজ

ভাল, আমি মনে করি এটি কেবল একটি "আলাদা" নিউলাইন (বেশিরভাগের চেয়ে আলাদা)

— গীতারিক

-১ সম্পাদন করার git config --global core.autocrlf trueজন্য গিটটিকে পুনরায় ইনস্টল করা ওভারকিল এবং বিরোধী উইন্ডোজ / বিরোধী CRপ্রচারাভিযানটি প্রশ্নের স্পর্শকাতর বলে মনে হয়।

— আরজেফালকোনার

Answer 6

"ডিফারিং করার সময় treat এমকে নতুন লাইন হিসাবে ট্রিট করুন" এর মতো বিকল্প নেই?

গিট 2.16 (Q1 2018) এর সাথে একটি থাকবে, কারণ diffকমান্ডের পরিবার " " লাইনের শেষে গাড়িতে ফেরার পার্থক্য উপেক্ষা করতে শিখেছে।

দেখুন e9282f0 কমিট (26 অক্টোবর 2017) দ্বারা junio সি Hamano ( gitster) ।
সহায়তা করেছেন: জোহানেস শিন্ডেলিন ( dscho) ।
^{(দ্বারা একীভূত junio সি Hamano - gitster- মধ্যে কমিট 10f65c2 , 27 নভেম্বর 2017)}

পরিবর্তন: --ignore-cr-at-eol

একটি নতুন বিকল্প পৃথক --ignore-cr-at-eolযন্ত্রগুলিকে একটি (সম্পূর্ণ) লাইনের শেষে ক্যারেজ-রিটার্নটি ট্রিট করতে বলে যাতে এটি উপস্থিত নেই।

--ignore-*বিভিন্ন ধরণের হোয়াইটস্পেসের পার্থক্য উপেক্ষা করার জন্য অন্যান্য বিকল্পগুলির মতো , এটি CRLF<->LFআপনার সম্পাদক প্রোগ্রাম দ্বারা উত্সাহিত রূপান্তর দ্বারা বিভ্রান্ত না হয়ে আপনি তৈরি প্রকৃত পরিবর্তনগুলি পর্যালোচনা করতে সহায়তা করবে ।

Comments

@ কার্টিক উত্তর সম্পাদনা করার জন্য এবং সঠিক প্রতিশ্রুতিবদ্ধ রেফারেন্স দেওয়ার জন্য আপনাকে ধন্যবাদ!

— ভনসি

সাধারণভাবে git config --global core.autocrlf trueগ্রহণযোগ্য উত্তরের মতো সেট করা ভাল অভ্যাস থাকলেও এটি ওপির প্রশ্নের আরও সরাসরি উত্তর দেয়: 'আলাদা করার সময় "treat M কে নতুন লাইনের হিসাবে বিবেচনা করার মতো" বিকল্প আছে কি?'

— drkvogel

গিট ২.২০ পর্যন্ত এটি

— মাইক্রোসফট

@ ব্যবহারকারী1944441 আমি কোনও প্রতিরোধের বিষয়টি লক্ষ্য করিনি, যার অর্থ গিট ২.২26 এ এই বিকল্পটির সাথে পৃথক হওয়ার সময় এটি ইলটিকে উপেক্ষা করে।

— ভনসি

@ ভনসি এই আর্গুমেন্টটি গিট ডিফ কমান্ডে ব্যবহার করে কাজ করে নি। অথবা আমার কোর.ওয়াইটসস্পেস মানটি সেট করে git version 2.20.1 (Apple Git-117)নি তবে জেসন পায়ারনের কোর.প্যাজার উত্তর যুক্ত করে এটি ঠিক করে দিয়েছে। ওয়াইএমএমভি স্পষ্টতই।

— ব্যবহারকারী 1944491

Answer 7

টি এল; ডিআর

পরিবর্তন core.pagerকরার জন্য "tr -d '\r' | less -REX", না সোর্স কোড

এই কারনে

দেখানো p মায়াময় ^ এম হ'ল রঙিনকরণ এবং পেজারের একটি নিদর্শন। এটি less -Rএকটি ডিফল্ট গিট পেজার বিকল্পের কারণে ঘটে । (গিটের ডিফল্ট পেজার হ'ল less -REX)

প্রথম যে জিনিসটি লক্ষ্য করুন তা হ'ল git diff -bসাদা স্থানের পরিবর্তনগুলি প্রদর্শন করবে না (যেমন the 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

আমরা নোট করি যে পাইপকে কম চাপ দেওয়া ^ এম দেখায় না, তবে রঙ সক্ষম 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, কারণ এটি কেবল রঙ কোডগুলি নয়, সমস্ত নিয়ন্ত্রণ কোডের মধ্য দিয়ে চলে যাবে pass

আপনি যদি কেবল নিজের গিট কনফিগারেশন ফাইলটি সরাসরি সম্পাদনা করতে চান তবে এটি আপডেট / যুক্ত করার জন্য এন্ট্রি:

[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আমি যা খুঁজছিলাম তা হ'ল তবে আমি পুরো ব্যাখ্যাটির প্রশংসা করি।

— মার্টিন বুর্চ

এই উত্তর! ধন্যবাদ. -বি পতাকাটি আমার পক্ষে কাজ করে নি।

— ক্রিস

হ্যাঁ! এই প্রশ্নের সমস্ত উত্তরগুলির মধ্যে, গিট "কনফিগারেশন" ফাইলের [core]বিভাগটি যুক্ত করে সংশোধন pager = tr -d '\\r' | less -REXকরা আমার পক্ষে কাজ করা একমাত্র উত্তর ছিল। ধন্যবাদ!

— রাশিকি

Answer 8

আমি দীর্ঘদিন এই সমস্যাটির সাথে লড়াই করেছি। এখন পর্যন্ত সবচেয়ে সহজ সমাধানটি হ'ল এম অক্ষরগুলির সম্পর্কে চিন্তা না করা এবং কেবলমাত্র একটি ভিজ্যুয়াল ডিফ সরঞ্জাম ব্যবহার করুন যা সেগুলি হ্যান্ডেল করতে পারে।

টাইপ করার পরিবর্তে:

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

ভনসি দ্বারা উল্লিখিত হিসাবে, এটি ইতিমধ্যে গিট 2.16+ তে অন্তর্ভুক্ত করা হয়েছে। দুর্ভাগ্যক্রমে, বিকল্পটির নাম ( --ignore-cr-at-eol) GNU দ্বারা ব্যবহৃত ব্যবহৃত থেকে আলাদা হয় যা আমি ব্যবহার করি ( --strip-trailing-cr)।

যখন আমি এই সমস্যার মুখোমুখি হয়েছিলাম তখন আমার সমাধানটি ছিল গিটের বিল্ট-ইন ডিফের পরিবর্তে জিএনইউ ডিফের অনুরোধ করা, কারণ আমার গিটটি ২.১ than এর চেয়ে বেশি পুরানো। আমি এই কমান্ড লাইনটি ব্যবহার করে তা করেছি:

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

এটি ব্যবহার করতে --strip-trailing-crএবং অন্য কোনও জিএনইউ পৃথক বিকল্পের অনুমতি দেয়।

এই অন্য উপায় আছে:

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

তবে এটি কনফিগার করা পেজার সেটিংস ব্যবহার করে না, এ কারণেই আমি আগেরটিকে পছন্দ করি।

Comments

আমার উত্তরের আকর্ষণীয় বিকল্প। সম্মত।

— ভোনসি