আমি কেন গিটারে কোর.আউটোক্রল্ফ = সত্য ব্যবহার করব?

Question

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

1. সেট core.autocrlfথেকে falseসর্বত্র,

2. নির্দেশাবলী অনুসরণ করুন এখানে (GitHub এর সাহায্যের পাতায় প্রতিধ্বনিত) সংগ্রহস্থলের রূপান্তর করতে শুধুমাত্র এলএফ লাইন শেষা w শ ধারণ করে, এবং তারপরে সেট core.autocrlfকরতে trueWindows এ এবং inputOS X এর উপর এই কাজ সঙ্গে সমস্যা হল যদি আমি সংগ্রহস্থলের মধ্যে কোন বাইনারি ফাইল আছে যে:

   1. গিটাট্রিবিউটে বাইনারি হিসাবে সঠিকভাবে চিহ্নিত নেই এবং
   2. উভয় সিআরএলএফ এবং এলএফ রয়েছে,

   তারা কলুষিত হবে। এটা সম্ভব আমার সংগ্রহস্থলে এ জাতীয় ফাইল রয়েছে।

তাহলে আমি কেন গিটের লাইন-এন্ডিং রূপান্তরটি বন্ধ করব না? core.autocrlfসমস্যা সৃষ্টি করার কারণে সুইচ অফ করে দেওয়ার বিষয়ে ওয়েবে প্রচুর অস্পষ্ট সতর্কতা রয়েছে তবে নির্দিষ্ট কিছু খুব কম ; আমি এখনও অবধি খুঁজে পেয়েছি যে কেডিফ 3 সিআরএলএফ শেষগুলি পরিচালনা করতে পারে না (আমার পক্ষে কোনও সমস্যা নয়), এবং কিছু পাঠ্য সম্পাদকদের লাইন-এন্ডিং ইস্যু রয়েছে (আমারও সমস্যা নয়)।

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

লাইন-এন্ডিংস ছেড়ে যাওয়ার ক্ষেত্রে কি অন্য কোনও সমস্যা রয়েছে যেটি সম্পর্কে আমি অজানা?

Comments

চান stackoverflow.com/questions/2333424/... সাহায্য করেছিল? autocrlfমিথ্যা ছেড়ে যাওয়ার নির্দিষ্ট কারণগুলির সাথে আমার লিঙ্ক রয়েছে ।

— ভনসি

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

— ধনী

@ ভনসি অর্থাৎ আমি autocrlfমিথ্যাতে সেট করার কারণ খুঁজছি না । আমি এটি সত্যে সেট করার কারণ অনুসন্ধান করছি।

— ধনী

কেন ব্যবহার করবেন না autocrlf = input: এটি দুটি চূড়ান্ততার মধ্যে নিখুঁত রেজোলিউশন বলে মনে হচ্ছে: আপনি সিআরএলএফ ক্রেপ থেকে আপনার রেপো পরিষ্কার রাখেন, এবং স্থানীয়ভাবে উইন্ডোজ বিকাশকারীরা তাদের স্থানীয় ফাইলগুলিতে স্বয়ংক্রিয়ভাবে কোনও যাদু না নিয়ে যা চান তা ব্যবহার করতে পারেন। (তারা বিভিন্ন কারণে স্থানীয়ভাবে এলএফ চেয়ে থাকতে পারে, তাই trueআমার মতে এটি খারাপ) I ব্যবহারের ক্ষেত্রে আমি কোনও ডাউনস্টাইড দেখতে পাচ্ছি না autocrlf = input।

— আইকনোক্ল্যাষ্ট

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

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

Answer 1

শুধুমাত্র নির্দিষ্ট কারণগুলি সেট autocrlfকরতে trueহবে:

• git statusআপনার modifiedউইন্ডোজটিতে ইউনিক্স-ভিত্তিক ইওল গিট রেপো ক্লোনিং করার সময় স্বয়ংক্রিয় ইওএল রূপান্তর হওয়ার কারণে আপনার সমস্ত ফাইলগুলি দেখাতে এড়াবেন ( উদাহরণস্বরূপ issue৩ সংখ্যা দেখুন )
• এবং আপনার কোডিং সরঞ্জামগুলি কোনওভাবে কোনও দেশীয় EOL শৈলী আপনার ফাইলে উপস্থিত থাকার উপর নির্ভর করে :
  • উদাহরণস্বরূপ, একটি কোড জেনারেটর দেশীয় EOL সনাক্ত করার জন্য হার্ড-কোডড
  • অন্যান্য বহিরাগত ব্যাচগুলি (আপনার রেপোর বাহ্যিক) দেশীয় ইওএল সনাক্ত করার জন্য রেজিএক্সপ বা কোড সেট সহ
  • আমি বিশ্বাস করি যে কিছু Eclipse প্লাগইন সিআরএলএফ দিয়ে প্ল্যাটফর্মে নির্বিশেষে ফাইল তৈরি করতে পারে, যা সমস্যা হতে পারে।
  • আপনি নোটপ্যাড.এক্সএই কোড দিয়েছিলেন ( যদি না আপনি উইন্ডোজ 10 2018.09+ ব্যবহার করেন না, যেখানে নোটপ্যাড ইওএল বর্ণচিহ্ন সনাক্ত করা সম্মান করে )।

আপনি যদি এমন নির্দিষ্ট চিকিত্সা না দেখতে পান যা অবশ্যই দেশীয় EOL এর সাথে ডিল করতে পারে তবে আপনি ( ) এ চলেautocrlffalse যাওয়াই ভাল git config --global core.autocrlf false।

নোট করুন যে এই কনফিগারটি স্থানীয় হবে (কারণ কনফিগারেশনটি রেপো থেকে রেপোতে ঠেলা যায় না)

আপনি যদি সেই রেপো ক্লোনিং করে এমন সমস্ত ব্যবহারকারীর জন্য একই কনফিগারেশন চান তবে ফাইলটিতে অ্যাট্রিবিউটটি ব্যবহার করে " গিট দিয়ে সেরা CRLFপরিচালনা করার কৌশলটি কী ? " দেখুন ।text.gitattributes

উদাহরণ:

*.vcproj    text eol=crlf
*.sh        text eol=lf

---

দ্রষ্টব্য: গিট ২.৮ (মার্চ ২০১ 2016) শুরু করে, মার্জ মার্কাররা আর কোনও সিআরএলএফ ফাইলে মিশ্রিত লাইন এন্ডিং (এলএফ) প্রবর্তন করবে না । "গিটটি এর" <<<<<<<< হেড "মার্জ লাইনগুলিতে সিআরএলএফ ব্যবহার করুন
দেখুন "

Comments

@ ভনসি ধন্যবাদ! এটি আমার আরও আত্মবিশ্বাস বোধ করতে সহায়তা করে যে এটি আমার পক্ষে ব্যবহার করা নিরাপদ autocrlf=false। আগ্রহের বাইরে, আপনি কি জানেন যে গিট এখনও অল রূপান্তর করে কেন আপনার অটোক্রল্ফটি মিথ্যাতে সেট থাকলেও?

— সমৃদ্ধ

@ ভনসি: আমি উত্তরটি সঠিক বলে মনে করি না is উইন্ডোজে কোর.আউটোক্রল্ফ = সত্য ব্যবহার করা প্রত্যাশা অনুযায়ী কাজ করে। রেপো থেকে সমস্ত ফাইল (যা এই দৃশ্যে এলএফ লাইনের শেষ হওয়া উচিত) উইন্ডোজ পিসিতে চেকআউটে সিআরএলএফ লাইন এন্ডিংয়ে রূপান্তরিত হয়। উইন্ডোজ পিসি থেকে কমিট করে সমস্ত ফাইল এলএফ লাইন এন্ডিংয়ে ফিরে আসে। সমস্যায় পড়ার উপায়টি হ'ল প্রাথমিকভাবে একটি উইন্ডোজ পিসিতে ভুল কোর.আউটোক্রল্ফ সেটিং (যা সম্পূর্ণরূপে করা সহজ নয়) দিয়ে চেকআউট করা।

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

@ মিশেল তাই core.autocrlf=falseসেক্ষেত্রে আমার দৃশ্যে ব্যবহার না করার একমাত্র কারণটি হ'ল যদি আমার কাছে এমন কোনও সরঞ্জাম / সম্পাদক থাকে যা লাইন-এন্ডিংয়ে বিভ্রান্ত হয়ে পড়ে?

— ধনী

আমি অবশ্যই ব্যবহার করব false, আমি কখনই পটভূমিতে ঘটে যাওয়া স্বয়ংক্রিয় বা যাদু বিষয়গুলির একটি বড় অনুরাগী হইনি। কেবল ব্যবহার করুন \nএবং UTF-8সর্বত্র এবং আপনি ভাল থাকবেন। যদি কিছু বাদাম-মাথা বুঝতে না পারে যে এখানে কনভেনশন এবং নিয়ম রয়েছে এবং ব্যবহার করতে ভুলে যায় UTF-8বা \n, তবে কেউ এগুলি ম্যানুয়ালি রূপান্তরিত করে এবং তার মুখের উপর চড় মারে।

— টাওয়ার

@ পল্ড'আউস্ট আমি এখনও এই ফাইলটির ধরণের জন্য নির্দিষ্ট করতে পছন্দ করব যে core.eolকোনও .gitattributesফাইলের মধ্যে সিআরএলএফ প্রয়োজন হয় না , এই বিশ্বব্যাপী core.autocrlfসেটিংটি ব্যবহার করার পরিবর্তে যা সমস্ত ফাইলের ক্ষেত্রে নির্বিচারে প্রয়োগ হয় ।

— ভনসি

Answer 2

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

বলা হচ্ছে, আমি ঘৃণা করি যে গিট আমার লাইনের শেষ পরিবর্তন করে। একটি উত্স নিয়ন্ত্রণ কেবল আমার করা কাজটি সংরক্ষণ এবং পুনরুদ্ধার করা উচিত, এটি এটিকে সংশোধন করা উচিত নয়। কখনো। তবে তা করে।

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

Comments

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

— ধনী

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

— জেজিটেলর

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

— টুনচে Göncüoğlu

যদি আপনার প্রকল্পটি উইন্ডোজ-কেবল হয় তবে কোনও সমস্যা নেই। তবে আপনি বা আপনার সহকর্মীরা যদি * নিক্স প্ল্যাটফর্মে কাজ করেন তবে আপনার "দৃ strong় সুপারিশ" সমস্যার কারণ হতে পারে। শেবাংটি শেষ হয়ে বাশ, পারল বা পাইথন স্ক্রিপ্ট চালানোর চেষ্টা করুন \r\nএবং আপনি দেখতে পাবেন।

— ফুক্লভ

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

— কোয়েটজলকোটল

Answer 3

আপডেট 2 :

এক্সকোড 9 এর একটি "বৈশিষ্ট্য" রয়েছে যা এটি ফাইলের বর্তমান লাইন শেষটিকে উপেক্ষা করবে এবং এর পরিবর্তে কেবলমাত্র আপনার ডিফল্ট লাইন-এন্ডিং সেটিংটি কোনও ফাইলে লাইন সন্নিবেশ করানোর সময় ব্যবহার করবে, ফলস্বরূপ মিশ্র লাইন শেষ হওয়া ফাইলগুলি।

আমি বেশ নিশ্চিত যে এই বাগটি এক্সকোড 7 এ উপস্থিত ছিল না; এক্সকোড ৮ সম্পর্কে নিশ্চিত নয় The সুসংবাদটি হ'ল এটি Xcode 10 এ স্থির হয়েছে বলে মনে হচ্ছে।

বিদ্যমান থাকাকালীন, এই বাগের ফলে আমি প্রশ্নে উল্লেখ করা কোডবেজে অল্প পরিমাণে আনন্দিত হতে পেরেছি (যা আজকের দিনটি ব্যবহার করে autocrlf=false), এবং অনেক "EOL" বার্তা দেয় এবং শেষ পর্যন্ত আমার লেখার গিট pre-commitহুক পরীক্ষা করে দেখায় মিশ্র লাইন শেষ প্রবর্তন জন্য / প্রতিরোধ।

আপডেট :

দ্রষ্টব্য: ভনসি দ্বারা উল্লিখিত হিসাবে, গিট ২.৮ থেকে শুরু করে মার্জ মার্কাররা উইন্ডোজ-স্টাইলের ফাইলটিতে ইউনিক্স-স্টাইলের লাইন- এন্ডিংগুলি প্রবর্তন করবে না ।

মূল :

এক সামান্য হিক্কা যে আমি এই সেটআপ লক্ষ্য করেছি যে যখন একত্রীকরণ দ্বন্দ্ব, লাইন Git পার্থক্য আপ চিহ্নিত করতে না যোগ করা হয় না আপনি আপ শেষ করতে পারেন উইন্ডোজ লাইন কোন শেষ, এমনকি যখন ফাইলের বাকি কাজ করে, এবং মিশ্র লাইনের সমাপ্তি সহ একটি ফাইল সহ, যেমন:

// Some code<CR><LF>
<<<<<<< Updated upstream<LF>
// Change A<CR><LF>
=======<LF>
// Change B<CR><LF>
>>>>>>> Stashed changes<LF>
// More code<CR><LF>

এটি আমাদের কোনও সমস্যা সৃষ্টি করে না (আমি কল্পনা করি যে কোনও সরঞ্জাম যা উভয় ধরণের লাইন-এন্ডিং পরিচালনা করতে পারে তাও মিশ্র লাইন-এন্ডিংয়ের সাথে বুদ্ধিমান আচরণ করবে - অবশ্যই আমরা ব্যবহার করি এমন সমস্ত বিষয়) তবে এটি সচেতন হওয়ার মতো কিছু বিষয়।

অন্যান্য জিনিস ^* আমরা পেয়েছি, যে যখন ব্যবহার git diffআছে যা উইন্ডোজ লাইন শেষা w শ, লাইন যে প্রদর্শন যোগ করা হয়েছে তাদের ঘোড়ার গাড়ি আয়, এইভাবে একটি ফাইলে পরিবর্তন এতে দেখতে:

    // Not changed

+   // New line added in^M
+^M
    // Not changed
    // Not changed

_{* এটি আসলে এই শব্দটির যোগ্যতা নয়: "ইস্যু"।}

Comments

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

— ধনী

দুর্ভাগ্যক্রমে কর্পোরেট সংস্করণ নিয়ন্ত্রণ নাজিস এটির সাথে একমত নয় (একীভূত সংঘাতের চিহ্নিতকারীদের উপর এলএফ) কোনও সমস্যা নয়।

— ইলিয়া জি

আমি সম্মত হই যে মার্জ সংঘাতের চিহ্নিতকারীদের এলএফ কোনও সমস্যা হওয়া উচিত নয়। এই লাইনগুলি যাইহোক রেপোতে প্রতিশ্রুতিবদ্ধ হওয়া উচিত নয়।

— রক

দ্রষ্টব্য: গিট ২.৮ (মার্চ ২০১)) শুরু করে, মার্জ মার্কারগুলিতে আসলে সিআরএলএফ লাইন শেষ হবে। দেখুন stackoverflow.com/a/35474954/6309

— VonC