বিভিন্ন অপারেটিং সিস্টেমের মধ্যে গিট কোর.আউটোক্রল্ফ দিয়ে লাইন শেষ রূপান্তর কীভাবে কাজ করে

Question

আমি স্ট্যাক ওভারফ্লোতে এবং কোর.আউটোক্রল্ফ সেটিং কীভাবে কাজ করে তা সম্পর্কে গিট ডকুমেন্টেশনগুলিতে প্রচুর বিভিন্ন প্রশ্ন এবং উত্তর পড়েছি ।

আমি যা পড়েছি তা থেকে এটি আমার বোঝার জন্য:

ইউনিক্স এবং ম্যাক ওএসএক্স (প্রাক-ওএসএক্স সিআর ব্যবহার করে) ক্লায়েন্টরা এলএফ লাইন শেষ ব্যবহার করে।
উইন্ডোজ ক্লায়েন্টরা সিআরএলএফ লাইন শেষ ব্যবহার করে।

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

এখানে এমন একটি ম্যাট্রিক্স রয়েছে যা কোর.আউটোক্রল্ফের 'ইনপুট' এবং 'মিথ্যা' সেটিংসের জন্য একই চিহ্ন নথিভুক্ত করার চেষ্টা করে যেখানে প্রশ্ন চিহ্ন রয়েছে যেখানে আমি লাইন শেষের রূপান্তর আচরণের বিষয়ে নিশ্চিত নই।

আমার প্রশ্নগুলি হ'ল:

1. প্রশ্ন চিহ্নগুলি কী হওয়া উচিত?
2. এই ম্যাট্রিক্স "প্রশ্নবিদ্ধ চিহ্নগুলি" জন্য সঠিক?

Conকমত্য গঠনের বিষয়টি মনে হচ্ছে বলে আমি উত্তরগুলি থেকে প্রশ্ন চিহ্নগুলি আপডেট করব।

                       কোর.আউটোক্রল্ফ মান
            সত্য ইনপুট মিথ্যা
-------------------------------------------------- --------
প্রতিশ্রুতিবদ্ধ | রূপান্তর? ?
নতুন | এলএফ (এলএফ রূপান্তর?) (রূপান্তর নেই?)

প্রতিশ্রুতিবদ্ধ | রূপান্তর ? না
বিদ্যমান | এলএফ (এলএফ রূপান্তর?) রূপান্তর

চেকআউট | রূপান্তর ? না
বিদ্যমান | CRLF (কোনও রূপান্তর নেই?) রূপান্তর

আমি সত্যিই বিভিন্ন সেটিংসের উপকারিতা এবং পক্ষে মতামত খুঁজছি না। আমি কেবল এমন ডেটা খুঁজছি যা এটি তিনটি সেটিংসের প্রতিটিটির সাথে গিট কীভাবে অপারেট করবে তা প্রত্যাশা করে।

-

আপডেট 04/17/2012 : মন্তব্যগুলিতে জেজেডি দ্বারা যুক্ত টিম ক্লেমের নিবন্ধটি পড়ার পরে , আমি উপরের টেবিলের "অজানা" মানগুলির কিছু মান সংশোধন করেছি, পাশাপাশি "চেকআউট বিদ্যমান | রূপান্তরিত করতে সত্য" ক্লায়েন্টে রূপান্তর করার পরিবর্তে সিআরএলএফ-এ রূপান্তর করুন। এখানে তিনি যে সংজ্ঞা দিয়েছেন সেগুলি এখানে রয়েছে যা আমি অন্য কোথাও দেখেছি তার থেকে আরও স্পষ্ট:

core.autocrlf = মিথ্যা

এটি ডিফল্ট, তবে বেশিরভাগ লোককে অবিলম্বে এটি পরিবর্তন করতে উত্সাহিত করা হয়। মিথ্যা ব্যবহারের ফলাফল হ'ল গিটটি আপনার ফাইলে লাইন শেষ হতে পারে না। আপনি এলএফ বা সিআরএলএফ বা সিআর বা এই তিনজনের কিছু এলোমেলো মিশ্রণের সাথে ফাইলগুলিতে চেক করতে পারেন এবং গিটের কোনও যত্ন নেই। এটি পড়ার পক্ষে বিভিন্নগুলিকে আরও শক্ত করে তুলতে পারে এবং আরও কঠিন করা হয়েছে। ইউনিক্স / লিনাক্স ওয়ার্ল্ডে কাজ করা বেশিরভাগ লোকেরা এই মানটি ব্যবহার করে কারণ তাদের সিআরএলএফ সমস্যা নেই এবং যখনই বস্তু ডাটাবেসে ফাইল লিখিত থাকে বা কার্য ডিরেক্টরিতে লেখা হয় তখন তাদের অতিরিক্ত কাজ করার দরকার হয় না।

core.autocrlf = সত্য

এর অর্থ হ'ল গিট সমস্ত পাঠ্য ফাইল প্রক্রিয়াকরণ করবে এবং নিশ্চিত করবে যে সিডিএলএফটি এলএফের সাথে প্রতিস্থাপন করা হয়েছে যখন সেই ফাইলটি অবজেক্ট ডাটাবেসে লেখার সময় এবং সমস্ত এলএফকে আবার সিআরএলএফ রূপান্তরিত করবে যখন কার্যকরী ডিরেক্টরিতে লেখার সময়। এটি উইন্ডোজে প্রস্তাবিত সেটিংস কারণ এটি নিশ্চিত করে যে আপনার ওয়ার্কিং ডিরেক্টরিতে সিআরএলএফ বজায় রেখে আপনার সংগ্রহশালাটি অন্য প্ল্যাটফর্মে ব্যবহার করা যেতে পারে।

core.autocrlf = ইনপুট

এর অর্থ হ'ল গিট সমস্ত পাঠ্য ফাইল প্রক্রিয়াকরণ করবে এবং নিশ্চিত করবে যে সিটিআরএলএফের সাথে এলএফের সাথে প্রতিস্থাপন করা হয়েছে যখন সেই ফাইলটি অবজেক্ট ডাটাবেসে লিখবেন। এটি তবে বিপরীত করবে না। আপনি যখন বস্তু ডাটাবেসের বাইরে ফাইলগুলি পড়েন এবং সেগুলি কার্যকরী ডিরেক্টরিতে লিখেন তখন তাদের কাছে লাইনের শেষ বোঝাতে এলএফ থাকবে। এই সেটিংটি সাধারণত ইউনিক্স / লিনাক্স / ওএস এক্স-এ ব্যবহৃত হয় সিআরএলএফগুলি সংগ্রহস্থলে লেখা থেকে রোধ করতে। ধারণাটি হ'ল আপনি যদি কোনও ওয়েব ব্রাউজার থেকে কোড পেস্ট করে এবং দুর্ঘটনাক্রমে আপনার ফাইলগুলির মধ্যে একটিতে সিআরএলএফস পেয়ে যান, গিট নিশ্চিত করবে যে আপনি যখন বস্তু ডাটাবেসে লিখেছেন তখন সেগুলি এলএফ দ্বারা প্রতিস্থাপিত হয়েছিল।

টিমের নিবন্ধটি দুর্দান্ত, আমি কেবল এটিই অনুপস্থিত মনে করতে পারি তা হ'ল তিনি ধারনা করেছিলেন যে রেপোজিটরিটি এলএফ ফর্ম্যাটে রয়েছে, যা প্রয়োজনীয়ভাবে সত্য নয়, বিশেষত উইন্ডোজ কেবলমাত্র প্রকল্পের ক্ষেত্রে।

জিমেলা দ্বারা তারিখের সর্বোচ্চ ভোট প্রাপ্ত উত্তরের সাথে টিমের নিবন্ধটির তুলনা করা সত্য এবং ইনপুট সেটিংসের উপর নিখুঁত চুক্তি এবং মিথ্যা সেটিং সম্পর্কে মতানৈক্য দেখায়।

Comments

রাখা autocrlf); মিথ্যাতে এত সহজ বলে মনে হয় stackoverflow.com/questions/2333424/...

— VonC

@ ভনসি: আমি এটি পড়েছি এবং আমার মনে হয় আমি এটি বুঝতে পেরেছি, তবে আমি পছন্দ করে বেছে নিতে পারি না। আমি গিট সংগ্রহস্থলগুলির সাথে কাজ করি যা আমি নিয়ন্ত্রণ করি না যে কে প্রয়োজন যে আমি নির্দিষ্ট উপায়ে মান নির্ধারণ করি।

— মাইকেল মাদডক্স

উইন্ডোজও যদি এলএফ-তে স্বাভাবিক হয়ে যায় তবে ভাল লাগবে না? ম্যাক সিআর (পূর্বে ভি 10) ব্যবহার করতেন তবে এখন এটি এলএফ-তে স্বাভাবিক করা হয়েছে।

— ব্রেট রায়ান

আমি মহান নিবন্ধ একটি লিঙ্ক যুক্ত করতে হবে টিমোথি ক্ষুধা হত্তয়া - সব পড়া দয়া মাইন্ড তোমার লাইনের শেষে ।

— জেজেডি

পরিস্থিতি: আমি একটি বিভক্ত লিনাক্স / উইন্ডোজ বিকাশকারী। আমি কেবলমাত্র পাঠ্য সম্পাদক ব্যবহার করি যা উভয় প্রকারের লাইনের সমাপ্তিগুলি (আই। ভিম, গ্রহন) সনাক্ত করতে পারে। আমার কেবল এলএফ-এ শেষ হওয়া ফাইলগুলির সাথে কাজ করতে (চাই) দরকার। আমার বর্তমানে আমার গ্লোবাল গিট কনফিগারেশনে কোর.আউটোক্রল্ফ = ইনপুট সেট রয়েছে। আমি কি ভাল? আমার কি কখনও দ্বন্দ্ব হবে?

— ক্রিস

Answer 1

গিটারট্রিবিটস ম্যান পৃষ্ঠাতে কীভাবে core.autocrlfকাজ করে তার সুনির্দিষ্ট বিবরণtext বৈশিষ্ট্য বিভাগে।

এটি বর্তমানে কীভাবে core.autocrlfকাজ করে প্রদর্শিত হয় (বা কমপক্ষে আমি যা জানি তা থেকে v1.7.2 থেকে):

• core.autocrlf = true
  1. সংগ্রহস্থল থেকে টেক্সট ফাইলগুলি যাচাই করা হয়েছে কেবলমাত্র LFঅক্ষর রয়েছে সেগুলি CRLFআপনার কার্যক্ষম গাছের মধ্যে স্বাভাবিক করা হয়েছে; CRLFসংগ্রহস্থলগুলিতে থাকা ফাইলগুলি স্পর্শ করা যাবে না
  2. LFসংগ্রহস্থলের কেবল অক্ষর রয়েছে এমন পাঠ্য ফাইলগুলি পুনরায় সংগ্রহস্থলটিতে প্রতিশ্রুতিবদ্ধ CRLFহওয়ার LFসময় থেকে স্বাভাবিক করা হয় । CRLFসংগ্রহস্থলগুলিতে থাকা ফাইলগুলি ছোঁয়াচে প্রতিশ্রুতিবদ্ধ হবে।
• core.autocrlf = input
  1. সংগ্রহশালা থেকে চেক-আউট পাঠ্য ফাইলগুলি আপনার কার্যকারী গাছের মধ্যে মূল EOL অক্ষর রাখবে।
  2. CRLFঅক্ষরগুলি সহ আপনার কার্যকারী বৃক্ষের পাঠ্য ফাইলগুলি LFপুনরায় সংগ্রহশালায় প্রতিশ্রুতিবদ্ধ হওয়ার সময় স্বাভাবিক করা হয় ।
• core.autocrlf = false
  1. core.eol আপনার কার্যকারী গাছের পাঠ্য ফাইলগুলিতে EOL টি অক্ষর নির্দেশ করে।
  2. core.eol = nativeডিফল্টরূপে, যার অর্থ উইন্ডোজ EOL গুলি CRLFএবং * নিক্স ইওলগুলি LFকার্যক্ষম গাছগুলিতে থাকে।
  3. সংগ্রহস্থল gitattributesসেটিংস EOL অক্ষরকে স্বাভাবিকের জন্য ভাণ্ডারগুলিতে প্রত্যাবর্তনের জন্য নির্ধারণ করে (ডিফল্ট LFঅক্ষরে স্বরূপকরণ হয় )।

আমি সম্প্রতি সম্প্রতি এই বিষয়টি নিয়ে গবেষণা করেছি এবং পরিস্থিতিটি খুব সংশ্লেষিত বলে মনে করি। core.eolসেটিং স্পষ্টভাবে নির্মল কিভাবে EOL অক্ষর Git দ্বারা পরিচালনা করা হয় সাহায্য করেছে।

Comments

অটোক্রোল্ফের জন্য = সত্যটি নিম্নলিখিত হওয়া উচিত নয়? সংগ্রহস্থলের কাছে পাঠ্য ফাইলগুলিতে কেবল সিআরএলএফ ইওএল অক্ষর রয়েছে, যখন পুনরায় সংগ্রহশালায় প্রতিশ্রুতিবদ্ধ হয় তখন সেগুলি সিআরএলএফ থেকে এলএফ থেকে স্বাভাবিক করা হয়। সংগ্রহস্থলে এলএফ থাকা ফাইলগুলি ছোঁয়াচে প্রতিশ্রুতিবদ্ধ হবে।

— পিয়োটার লেয়ান্ডোভস্কি

আমার জন্য, এমনকি যদি autocrlf = মিথ্যা গিট EOL কে CRLF এ রূপান্তর করে। এই উত্তরটি পড়ার পরে আমি বুঝতে পারি যে আমার .gitattribute ফাইলটিতে টেক্সট = অটো সেট রয়েছে যা সমস্যার কারণ হচ্ছিল।

— ইরসিস

কারণ core.autocrlf = false, আমার কাছে gitattributesফাইল না থাকলে এর অর্থ কি কোনও স্বাভাবিকীকরণ থাকবে না? বা এর অর্থ এটি ডিফল্ট স্বাভাবিককরণ ব্যবহার করবে?

— চিন

.gitattributesফাইলটি core.autocrlfসেটিংয়ের চেয়ে বেশি প্রাধান্য দেওয়া উচিত নয় ?

— কিওয়ার্টি

Answer 2

মিশ্র-প্ল্যাটফর্ম প্রকল্পগুলিতে EOL এর বিষয়টি আমার জীবনকে দীর্ঘকাল ধরে দুর্বিষহ করে তুলেছে। ইতোমধ্যে রেপোতে ইতিমধ্যে বিভিন্ন এবং মিশ্র ইওলযুক্ত ফাইল থাকা অবস্থায় সমস্যাগুলি দেখা দেয় । এই যে মানে:

1. রেপোতে বিভিন্ন ইওল সহ বিভিন্ন ফাইল থাকতে পারে
2. রেপোর কিছু ফাইলের EOL মিশ্র থাকতে পারে, উদাহরণস্বরূপ CRLFএবং LFএকই ফাইলের সংমিশ্রণ ।

এটি কীভাবে হয় তা এখানে সমস্যা নয়, তবে তা ঘটে।

আমি বিভিন্ন মোড এবং তাদের সংমিশ্রণের জন্য উইন্ডোজটিতে কিছু রূপান্তর পরীক্ষা চালিয়েছি।
আমি সামান্য পরিবর্তিত টেবিল এ যা পেয়েছি তা এখানে:

                 | যখন রূপান্তর ফলাফল যখন রূপান্তর ফলাফল
                 | বিভিন্ন সঙ্গে ফাইল প্রতিশ্রুতিবদ্ধ FROM রেপো পরীক্ষা করা হচ্ছে -
                 | EOL গুলি INTO REPO এবং | এতে মিশ্র ফাইল রয়েছে এবং
                 | core.autocrlf মান: | কোর.আউটোক্রল্ফ মান:           
-------------------------------------------------- ------------------------------
ফাইল | সত্য | ইনপুট | মিথ্যা | সত্য | ইনপুট | মিথ্যা
-------------------------------------------------- ------------------------------
উইন্ডোজ-সিআরএলএফ | সিআরএলএফ -> এলএফ | সিআরএলএফ -> এলএফ | যেমন হয় | যেমন হয় | যেমন হয় | যেমন-is
ইউনিক্স -এলএফ | যেমন হয় | যেমন হয় | যেমন হয় | এলএফ -> সিআরএলএফ | যেমন হয় | যেমন-is
ম্যাক-সিআর | যেমন হয় | যেমন হয় | যেমন হয় | যেমন হয় | যেমন হয় | যেমন-is
মিশ্র-সিআরএলএফ + এলএফ | যেমন হয় | যেমন হয় | যেমন হয় | যেমন হয় | যেমন হয় | যেমন-is
মিশ্র-সিআরএলএফ + এলএফ + সিআর | যেমন হয় | যেমন হয় | যেমন হয় | যেমন হয় | যেমন হয় | যেমন-is

যেমন আপনি দেখতে পাচ্ছেন, রূপান্তরটি কমিট (3 বাম কলাম) এ ঘটে তখন 2 টি ঘটনা ঘটে। বাকি ক্ষেত্রে ফাইলগুলি যেমন রয়েছে তেমন প্রতিশ্রুতিবদ্ধ।

চেকআউট (3 টি ডান কলাম) এ, কেবলমাত্র 1 টি কেস রয়েছে যেখানে রূপান্তর ঘটে যখন:

1. core.autocrlfহয় true এবং
2. LFরেপোতে ফাইলটির EOL রয়েছে।

আমার জন্য সবচেয়ে অবাক করা এবং আমি সন্দেহ করি যে অনেক EOL সমস্যার কারণ হ'ল এমন কোন কনফিগারেশন নেই যা মিশ্রিত EOL এর মতো CRLF+ সাধারণীকরণ হয় LF।

এছাড়াও মনে রাখবেন যে CRশুধুমাত্র "পুরানো" ম্যাক ইওলগুলি কখনও রূপান্তরিত হয় না।
এর অর্থ হ'ল যদি কোনও খারাপভাবে লিখিত EOL রূপান্তর স্ক্রিপ্টটি কেবলমাত্র এসকে এস- তে রূপান্তরিত করে একটি মিশ্র প্রান্তিক ফাইলকে CRLFs + LFs এর সাথে রূপান্তরিত করার চেষ্টা করে , তবে যেখানেই রূপান্তরিত হয়েছিল সেখানে ফাইলটি "একাকী" দিয়ে একটি মিশ্র মোডে রেখে যাবে । গিটটি তখন কোনও রূপে রূপান্তর করবে না এমনকি মোডেও, এবং EOL এর সর্বনাশ অবিরত থাকবে। এটি আসলে আমার সাথে ঘটেছিল এবং আমার ফাইলগুলি সত্যই খারাপভাবে গণ্ডগোল করে দেয়, যেহেতু কিছু সম্পাদক এবং সংকলক (যেমন VS2010) ম্যাক ইওলগুলি পছন্দ করে না।LFCRLFCRCRLFCRCRLF
true

আমি অনুমান করি যে এই সমস্যাগুলিকে সত্যই হ্যান্ডেল করার একমাত্র উপায় হ'ল মাঝেমধ্যে সমস্ত ফাইলগুলি inputবা falseমোডে যাচাই করে একটি যথাযথ নরমালাইজেশন চালানো এবং পরিবর্তিত ফাইলগুলি পুনরায় প্রতিশ্রুতিবদ্ধ করে (যদি থাকে) whole উইন্ডোজে, সম্ভবত পুনরায় কাজ শুরু করুন core.autocrlf true।

Comments

দুর্দান্ত উত্তর, তবে একটি বাক্য যার সাথে আমি একমত হতে পারি না তা হ'ল উইন্ডোজ অন, সম্ভবত এটির সাথে কাজ শুরু করুনcore.autocrlf true । আমি ব্যক্তিগতভাবে বিশ্বাস করি যা inputসর্বদা ব্যবহার করা উচিত।

— জি ডেমেকি

Answer 3

"ইওল রূপান্তর" ফ্রন্টে আসন্ন গিট 1.7.2 এর সাথে জিনিসগুলি পরিবর্তন হতে চলেছে :

একটি নতুন কনফিগারেশন সেটিং core.eolযুক্ত / বিবর্তিত হচ্ছে :

এটি বর্তমানে থাকা core.eol"কনফিগার ভেরিয়েবল" কমিটের প্রতিস্থাপন pu(এটি আমার সিরিজের শেষটি)।
পরিবর্তে implying যে " core.autocrlf=true" এর জন্য একটি প্রতিস্থাপন হল " * text=auto", এটা স্পষ্ট যে তোলে autocrlfএমন একজন সংগ্রহস্থলের যে টেক্সট ফাইল নিয়মমাফিককরণ নেই তাদের কাজ ডিরেক্টরির মধ্যে CRLFs সাথে কাজ করতে চান ব্যবহারকারীদের জন্য শুধুমাত্র হয় ।
এটি সক্ষম করা হলে, "কোর.ইওল" উপেক্ষা করা হয়।

একটি নতুন কনফিগারেশন ভেরিয়েবল প্রবর্তন করুন, " core.eol" যা ব্যবহারকারীকে কার্য-ডিরেক্টরিতে লাইন-এ-লাইন-নরমালাইজড ফাইলগুলির জন্য কোন লাইনের শেষটি ব্যবহার করতে হবে তা সেট করার অনুমতি দেয়।
এটি ডিফল্ট " native" এর সাথে, যার অর্থ উইন্ডোজ এবং এলএফ-এ অন্যত্র CRLF। লক্ষ্য করুন যে " core.autocrlf" ওভাররাইড হয় core.eol।
এই যে মানে:

[core]
  autocrlf = true

core.eol" lf" সেট করা থাকলেও কর্মরত ডিরেক্টরিতে সিআরএলএফ রাখে ।

core.eol:

textসম্পত্তি সেট থাকা ফাইলগুলির জন্য ওয়ার্কিং ডিরেক্টরিতে ব্যবহার করতে লাইন সমাপ্তির ধরন সেট করে।
বিকল্পগুলি হল 'এলএফ', 'ক্রল্ফ' এবং 'নেটিভ', যা প্ল্যাটফর্মের নেটিভ লাইন সমাপ্তি ব্যবহার করে।
ডিফল্ট মান native।

---

অন্যান্য বিবর্তন বিবেচনা করা হচ্ছে :

১.৮-এর জন্য, আমি core.autocrlfকেবলমাত্র নরমালাইজেশন চালু করার বিষয়ে বিবেচনা করব এবং ওয়ার্কিং ডিরেক্টরি লাইনটি শেষের সিদ্ধান্তটি কোর.ইওল এ ছেড়ে দেব, তবে এটি মানুষের সেটআপগুলি ভেঙে দেবে ।

---

গিট ২.৮ (মার্চ core.autocrlf২০১ )) ইওলকে প্রভাবিত করার উপায়টিকে উন্নত করে :

দেখুন কমিট 817a0c7 (23 ফেব্রুয়ারী 2016), 6e336a5 কমিট , df747b8 কমিট , df747b8 কমিট , (10 ফেব্রুয়ারী 2016) df747b8 কমিট , df747b8 কমিট (10 ফেব্রুয়ারী 2016), এবং 4b4024f কমিট , bb211b4 কমিট , 92cce13 কমিট , 320d39c কমিট , 4b4024f কমিট , প্রতিশ্রুত বিবি 1111 বি 4 , কমিট 92cce13 , কমিট 320d39c (05 ফেব্রুয়ারী 2016) টর্স্টেন বার্গারসৌসেন ( 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 রূপান্তর eol=বা autocrlfসেটিংস থেকে এবং " clean" ফিল্টারগুলি) ফাইলগুলি যখন কার্য-বৃক্ষ থেকে সূচীতে স্থানান্তরিত হয় , অর্থাত্ সময়ের git addপরিবর্তে চলাকালীন git commit।
(নোট করুন git commit -aবা --onlyবা --includeসেই সময়ে সূচীতে ফাইল যুক্ত করুন।)

তার আরও তথ্যের জন্য, " অটোক্রোল্ফ এবং ইওলের মধ্যে পার্থক্য কী " তা দেখুন ।

Comments

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

— মাইকেল মাদডক্স

এটি সন্তোষজনক সমাধানের মতো বলে মনে হচ্ছে না এবং कोर.আউটোক্রল্ফের মতো একই সমস্যা রয়েছে বলে মনে হচ্ছে। আমার পছন্দটি হ'ল যদি গিটটি কখনই স্বয়ংক্রিয়ভাবে কোনও কিছু সংশোধন না করে তবে এটি যে ব্যবহারকারীকে ভুল লাইন শেষ করতে বা প্রতিশ্রুতিবদ্ধ করতে চায় তাদের সতর্ক করে দেবে। সুতরাং "গিট অ্যাড" কে "ভুল" লাইন শেষটি যুক্ত করতে আপনার কমান্ডলাইন বিকল্পের প্রয়োজন হবে need (সম্ভবত গিট অ্যাড এটি গিট

— কমিটের

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

— donquixote

আবার ডনকুইক্সোট, আমি সম্মত। তবে core.eolকেবলমাত্র আপনি স্বয়ংক্রিয়ভাবে কোনও ফাইলটিতে যা ঘোষণা করেন তা "স্বয়ংক্রিয়ভাবে সংশোধন" সম্পর্কে .gitattributes। এটি আলাদা core.autocrlfযা রেপোর যে কোনও ফাইলের জন্য প্রযোজ্য । এটি একটি ঘোষণামূলক প্রক্রিয়া।

— ভনসি

@ ডনকুইক্সোট: আমি বুঝতে পারি এটি বেশ পুরানো তবে আমি এখন আপনার মন্তব্যটি পড়েছি। প্রকৃতপক্ষে, এই সমস্ত অনুবাদগুলি (ইওল = বা অটোক্রল্ফ সেটিংস থেকে যে কোনও ইওএল রূপান্তর এবং "ক্লিন" ফিল্টারগুলি) ফাইলগুলি যখন ওয়ার্ক-ট্রি থেকে সূচীতে স্থানান্তরিত করে, তখন সময় git addপরিবর্তে চলাকালীন চালানো হয় git commit। (নোট যে git commit -aবা --onlyবা --include, যে সময়ে সূচক অ্যাড ফাইল না যদিও।) কি এটা এর মূল্য তুমি আর আমি এবং লিনাস টোরভাল্ডস সব VCS ধারণা ঘৃণা জন্য কি পরিবর্তন কি সংঘটিত হচ্ছে। তবে সেই সমস্ত উইন্ডোজ ব্যবহারকারী রয়েছে ... :-)

— টেরিক

Answer 4

core.autocrlfমান ওএস টাইপের উপর নির্ভর করে না তবে উইন্ডোজ ডিফল্ট মান 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

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

core.autocrlf=false

আপনার কাছে একটি সংগ্রহশালা রয়েছে যা ইতিমধ্যে মেশানো লাইন এন্ডিংস চেক ইন করেছে এবং ভুল লাইন এন্ডিংস ঠিক করা অন্য জিনিসগুলিকে ভেঙে দিতে পারে। এক্ষেত্রে লাইন এন্ডিংগুলিকে রূপান্তর করতে গিটকে না বলা ভাল, কারণ এরপরে এটি যে সমস্যার সমাধান করার জন্য ডিজাইন করা হয়েছিল তা আরও বাড়িয়ে তুলবে - পড়ার পক্ষে বিভিন্নটিকে আরও সহজ করে তোলে এবং কম বেদনাদায়ক সংশ্লেষ করে। এই সেটিং সহ, গিট আপনার ফাইলগুলিকে সংশোধন করে না ।

core.autocrlf=input

আমি এটি ব্যবহার করি না কারণ এর কারণ হ'ল এমন একটি ব্যবহারের ক্ষেত্রে কভার করা যেখানে আপনি এমন একটি ফাইল তৈরি করেছিলেন যেখানে প্ল্যাটফর্মে সিআরএলএফ লাইন শেষ থাকে যা এলএফ লাইনের শেষের ডিফল্ট হয়। আমি পরিবর্তে আমার পাঠ্য সম্পাদকটিকে প্ল্যাটফর্মের লাইন শেষ হওয়া ডিফল্ট দিয়ে নতুন ফাইলগুলি সংরক্ষণ করার জন্য পছন্দ করি।

Answer 6

না, @ jmlane উত্তরটি ভুল।

এর জন্য Checkin (git add, git commit):

1. textসম্পত্তি যদি হয়Set, Set value to 'auto' তবে রূপান্তর ঘটে যখন ফাইলটি 'সিআরএলএফ' দিয়ে প্রতিশ্রুতিবদ্ধ হয়
2. textসম্পত্তি যদি হয়Unset : কিছুই হয় না, জন্যCheckout
3. textসম্পত্তি যদি হয় তবে Unspecifiedরূপান্তর নির্ভর করেcore.autocrlf
   1. যদি autocrlf = input or autocrlf = true , রূপান্তর কেবল তখনই ঘটে যখন ভাণ্ডারগুলিতে ফাইলটি 'এলএফ' হয়, যদি এটি 'সিআরএলএফ' হয়ে থাকে তবে কিছুই ঘটবে না।
   2. যদি autocrlf = false, কিছু না ঘটে

এর জন্য Checkout:

1. textসম্পত্তি যদি হয়Unset : কিছুই হয় না।
2. textসম্পত্তি যদি হয় Set, Set value to 'auto: এটি উপর নির্ভর করে core.autocrlf,core.eol ।
   1. core.autocrlf = ইনপুট: কিছুই হয় না
   2. core.autocrlf = সত্য: রূপান্তর কেবল তখনই ঘটে যখন সংগ্রহস্থলের ফাইলটি 'এলএফ', 'এলএফ' -> 'সিআরএলএফ' হয়
   3. core.autocrlf = মিথ্যা: রূপান্তর কেবল তখনই ঘটে যখন সংগ্রহস্থলের ফাইলটি 'LF', 'LF' হয় -> core.eol
3. textসম্পত্তি যদি হয় Unspecified, এটি উপর নির্ভর করে core.autocrlf।
   1. হিসাবে একই 2.1
   2. হিসাবে একই 2.2
   3. কিছুই নয়, কিছুই ঘটে না, textসম্পত্তি থাকাকালীন কোর.ইওল কার্যকর হয় নাUnspecified

ডিফল্ট আচরণ

সুতরাং ডিফল্ট আচরণ textসম্পত্তি হয় Unspecifiedএবং core.autocrlf = false:

1. চেকিনের জন্য, কিছুই হয় না
2. চেকআউটের জন্য, কিছুই ঘটে না

উপসংহার

1. যদি text সম্পত্তি সেট করা থাকে, আচরণ চেক ইন করে হয় autocrlf নিজে উপর নির্ভর করে, না
2. অটোক্রল্ফ বা কোর.ইল চেকআউট আচরণের জন্য এবং অটোক্রোল্ফ> কোর.ইওল

Answer 7

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

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