ما هو أفضل CRLF (إرجاع خط تغذية) التعامل مع استراتيجية مع Git ؟

Question

حاولت ارتكاب الملفات مع CRLF تنتهي خطوط, لكنها فشلت.

قضيت يوم عمل كامل على جهاز الكمبيوتر الخاص بك ويندوز محاولة استراتيجيات مختلفة و تقريبا الانتباه إلى التوقف عن محاولة استخدام بوابة والتركيز بدلا من ذلك الزئبقي.

يرجى حصة واحدة فقط أفضل الممارسات في الإجابة.

Answer 1

تقريبا بعد أربع سنوات من طرح هذا السؤال ، وأخيرا وجدت إجابة ترضي تماما لي!

انظر التفاصيل في جيثب:مساعدة's دليل التعامل مع خط النهايات.

بوابة يسمح لك تعيين خط النهاية خصائص الريبو مباشرة باستخدام سمة النص في .gitattributes الملف.هذا الملف هو المرتكبة في الريبو يتجاوز core.autocrlf الإعداد ، مما يسمح لك لضمان اتساق السلوك للجميع المستخدمين بغض النظر عن بوابة الإعدادات.

وهكذا

وميزة هذا هو نهاية السطر التكوين الآن يسافر مع المستودع الخاص بك و لك لا داعي للقلق حول ما إذا كان أو لا المتعاونين المناسبة إعدادات عمومية.

هنا مثال من .gitattributes الملف

# Auto detect text files and perform LF normalization
*        text=auto

*.cs     text diff=csharp
*.java   text diff=java
*.html   text diff=html
*.css    text
*.js     text
*.sql    text

*.csproj text merge=union
*.sln    text merge=union eol=crlf

*.docx   diff=astextplain
*.DOCX   diff=astextplain

# absolute paths are ok, as are globs
/**/postinst* text eol=lf

# paths that don't start with / are treated relative to the .gitattributes folder
relative/path/*.txt text eol=lf

هناك مريحة مجموعة جاهزة للاستخدام .gitattributes الملفات عن لغات البرمجة الأكثر شعبية.انها مفيدة للحصول على انك بدأته.

بمجرد إنشاء أو تعديل .gitattributes, ، يجب أن تؤدي مرة واحدة للجميع خط النهايات إعادة تطبيع.

علما بأن جيثب سطح المكتب التطبيق يمكن أن توحي وخلق .gitattributes الملف بعد فتح المشروع الخاص بك بوابة إعادة الشراء في التطبيق.في محاولة ذلك ، انقر على رمز الترس (في الزاوية اليمنى العليا) > إعدادات المستودع ...> خط النهايات و الصفات.سيطلب منك إضافة الموصى بها .gitattributes و إذا كنت توافق التطبيق أيضا إجراء تطبيع جميع الملفات الموجودة في المخزون الخاص بك.

أخيرا ، العقل نهاية الخط الخاص بك المادة يوفر المزيد من الخلفية و يشرح كيف بوابة تطورت على الأمور في متناول اليد.أنا أعتبر هذا القراءة المطلوبة.

ربما كنت قد حصلت على المستخدمين في الفريق الذين يستخدمون ايجت أو JGit (أدوات مثل الكسوف و TeamCity استخدامها) ارتكاب التغييرات الخاصة بهم.ثم كنت خارجا من الحظ ، كما @gatinueta وأوضح في هذا الجواب التعليقات:

هذا الإعداد لن يرضيك تماما إذا كنت من الأشخاص الذين يعملون مع ايجت أو JGit في فريقك ، منذ تلك الأدوات سوف تتجاهل فقط .gitattributes وسعادة تحقق في CRLF الملفات https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372

خدعة واحدة يمكن أن يكون لهم ارتكاب هذه التغييرات في عميل آخر ، ويقول SourceTree.فريقنا مرة أخرى ثم يفضل أن الكسوف هو ايجت على العديد من حالات الاستخدام.

من قال أن البرنامج هو سهل ؟ :-/

Answer 2

ولا تحويل خط النهايات. انها ليست وظيفة VCS لتفسير البيانات - فقط تخزين ونسخة منه. كل محرر نص الحديث يمكن قراءة كل أنواع من النهايات خط على أي حال.

Answer 3

كنت دائما تقريبا تريد autocrlf=input إلا إذا كنت تعرف حقا ما تقومون به.

بعض السياق إضافية أدناه:

يجب أن تكون إما core.autocrlf=true إذا كنت تحب دوس إنهاء أو core.autocrlf=input إذا كنت تفضل يونكس أسطر.في كل الحالات, بوابة المستودع ، فقط لو ، وهو الصواب.فقط حجة core.autocrlf=false كان التلقائي الكشف عن مجريات الأمور قد بشكل غير صحيح الكشف عن بعض الثنائية كما نص ثم البلاط الخاص بك سوف يكون معطوبا.لذلك ، core.safecrlf خيار عرض لتحذير المستخدم إذا وهي العملية غير قابلة للعودة تغيير يحدث.في الواقع ، هناك نوعان من إمكانيات العملية غير قابلة للعودة التغييرات -- مختلطة خط النهاية في ملف نصي في هذا التطبيع هو مرغوب فيه ، لذلك هذا التحذير يمكن تجاهلها ، أو (مستبعد جدا) أن Git بشكل غير صحيح الكشف عن الخاص بك ملف ثنائي كنص.ثم كنت بحاجة إلى استخدام الصفات أقول Git أن هذا الملف هو ثنائي.

الفقرة أعلاه أصلا سحبت من الخيط على gmane.org ولكن منذ ذلك الحين ذهب إلى أسفل.

Answer 4

اثنين من الاستراتيجيات البديلة إلى على الدوام عن خط النهايات في البيئات المختلطة (Microsoft + لينكس + Mac):

A.العالمية في جميع مستودعات الإعداد

1) تحويل كل واحد شكل

find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'

2) مجموعة core.autocrlf إلى input على لينكس/يونكس أو true على مايكروسوفت ويندوز (مستودع أو العالمية)

git config --global core.autocrlf input

3) [ اختياري ] مجموعة core.safecrlf إلى true (إيقاف) أو warn (الغناء:) لإضافة المزيد الحرس مقارنة إذا كان عكس السطر التحول من شأنه أن يؤدي في نفس الملف

git config --global core.safecrlf true

ب.أو في مستودع الإعداد

1) تحويل كل واحد شكل

find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'

2) إضافة .gitattributes ملف إلى المستودع الخاص بك

echo "* text=auto" > .gitattributes
git add .gitattributes
git commit -m 'adding .gitattributes for unified line-ending'

لا تقلق حول الملفات الثنائية - بوابة ينبغي أن تكون ذكية بما فيه الكفاية عنهم.

---

المزيد عن safecrlf/autocrlf المتغيرات

Answer 5

وحاول وضع خيار التكوين core.autocrlf إلى true. لديهم أيضا نظرة على خيار core.safecrlf.

والواقع أنه يبدو وكأنه core.safecrlf قد يكون تم تعيين في المخزون الخاص بك، وذلك لأن (التشديد من الألغام):

<اقتباس فقرة>   

إذا لم تكن هذه هي الحال بالنسبة للوضع الحالي للcore.autocrlf، <م> بوابة سيرفض الملف .

وإذا كان هذا هو الحال، فإنك قد ترغب في التحقق من تكوين محرر النص الخاص بك لاستخدام خط النهايات باستمرار. أنت من المحتمل أن واجهت مشاكل إذا ملف نصي يحتوي على مزيج من LF وCRLF خط النهايات.

وأخيرا، أشعر أن هذه التوصية إلى مجرد "استخدام ما كنت أعطيت" واستخدام LF إنهاء خطوط على ويندوز سوف يسبب المزيد من المشاكل أكثر مما يحل. بوابة لديه الخيارات المذكورة أعلاه لمحاولة التعامل مع نهايات خط بطريقة معقولة، لذلك فمن المنطقي لاستخدامها.

Answer 6

وعن طريق core.autocrlf=false توقف كافة الملفات من يجري ملحوظ تحديثها بأسرع ما راجعت بها في البصرية ستوديو 2010 مشروع . كما تستخدم الآخرين في فريق التطوير عضوين أنظمة ويندوز حتى بيئة مختلطة لم يدخل حيز اللعب، إلا أن الإعدادات الافتراضية التي تأتي مع مستودع دائما وضع علامة على كافة الملفات والتي يتم تحديثها فورا بعد استنساخ.

واعتقد ان خلاصة القول هي أن تجد ما يعمل الإعداد CRLF للبيئة الخاصة بك. خصوصا أنه في كثير من مستودعات أخرى على صناديق لينكس لدينا وضع autocrlf = true يؤدي إلى نتائج أفضل.

وبعد 20+ سنوات ونحن ما زلنا نتعامل مع خط إنهاء الفوارق بين أنظمة تشغيل ... حزين.

Answer 7

هذه هي اثنين من الخيارات ويندوز و Visual Studio المستخدمين التي تشترك مع رمز ماك أو لينكس المستخدمين.تمديد تفسير, قراءة gitattributes دليل.

* النص=auto

في الريبو هو .gitattributes إضافة ملف:

*   text=auto

هذا تطبيع جميع الملفات مع LF خط النهايات في الريبو.

و اعتمادا على نظام التشغيل الخاص بك (core.eol الإعداد), الملفات الموجودة في شجرة العمل سيتم تطبيع إلى LF Unix النظم القائمة أو CRLF على أنظمة ويندوز.

هذا هو التكوين الذي مايكروسوفت .صافي repos استخدام.

على سبيل المثال:

Hello\r\nWorld

سيتم تطبيع في الريبو دائما:

Hello\nWorld

على الخروج ، شجرة العمل في ويندوز سيتم تحويلها إلى:

Hello\r\nWorld

على الخروج ، شجرة العمل في ماك سوف تترك مثل:

Hello\nWorld

ملاحظة:إذا كان الخاص بك الريبو بالفعل يحتوي على ملفات لا تطبيع ، git status سوف تظهر هذه الملفات تماما كما عدلت في المرة القادمة يمكنك إجراء أي تغيير عليها ، ويمكن أن يكون الألم للمستخدمين الآخرين دمج التغييرات الخاصة بهم في وقت لاحق.انظر منعش مستودع بعد تغيير خط النهايات للحصول على مزيد من المعلومات.

الأساسية.autocrlf = true

إذا text غير محدد في .gitattributes ملف, بوابة يستخدم core.autocrlf تكوين متغير لتحديد ما إذا كان يجب أن يكون الملف تحويلها.

لمستخدمي ويندوز ، git config --global core.autocrlf true هو خيار كبير بسبب:

• الملفات هي طبيعية إلى LF خط النهايات فقط عندما تضاف إلى الريبو.إذا كان هناك ملفات لا تطبيع في الريبو هذا الإعداد لا تلمس لهم.
• جميع ملفات نصية يتم تحويلها إلى CRLF خط النهايات في دليل العمل.

المشكلة مع هذا النهج هو أن:

• إذا كنت مستخدم ويندوز مع autocrlf = input, سوف ترى مجموعة من الملفات مع LF خط النهايات.ألا يشكل خطرا على بقية الفريق, لأن يرتكب سوف لا يزال يتم تطبيع مع LF خط النهايات.
• إذا كنت مستخدم ويندوز مع core.autocrlf = false, سوف ترى مجموعة من الملفات مع LF خط النهايات و قد أعرض الملفات مع CRLF خط النهايات إلى الريبو.
• معظم مستخدمي ماك استخدام autocrlf = input و قد تحصل على الملفات مع CRLF الملف النهايات ، ربما من مستخدمي ويندوز مع core.autocrlf = false.

Answer 8

هذا هو مجرد الحل الحل:

في الحالات العادية ، استخدام الحلول التي يتم شحنها مع بوابة.هذه العمل العظيم في معظم الحالات.القوة إذا إذا كنت تشارك في التنمية على ويندوز و يونيكس النظم القائمة من خلال وضع .gitattributes.

في حالتي كانت هناك >10 المبرمجين على تطوير المشروع في نظام التشغيل Windows.هذا المشروع كان دخل مع CRLF ، لم يكن هناك أي خيار القوة إذا.

بعض الإعدادات داخليا مكتوب على الجهاز من دون أي تأثير على إن الشكل ؛ وهكذا بعض الملفات عالميا تغيير اذا على كل صغيرة تغيير الملف.

الحل:

Windows-الآلات: دع كل شيء كما هو.تهتم بأي شيء منذ كنت الافتراضي ويندوز 'الذئب' المطور لديك للتعامل مع مثل هذا:"لا يوجد نظام في العالم؟"

Unix-آلات

1. إضافة الأسطر التالية إلى ملف config هو [alias] القسم.يسرد هذا الأمر تغير كل شيء (أيتعديل/جديد) الملفات:

   lc = "!f() { git status --porcelain \
                | egrep -r \"^(\?| ).\*\\(.[a-zA-Z])*\" \
                | cut -c 4- ; }; f "
   

2. تحويل كل تلك تغيرت الملفات في دوس الشكل:

   unix2dos $(git lc)
   

3. اختياريا ...

   1. إنشاء بوابة هوك هذا العمل لأتمتة هذه العملية

   2. استخدام params وإدراجه وتعديل grep وظيفة مباراة معينة فقط أسماء الملفات ، على سبيل المثال:

      ... | egrep -r "^(\?| ).*\.(txt|conf)" | ...
      

   3. لا تتردد في جعل الأمر أكثر سهولة باستخدام الاختصار إضافية:

      c2dos = "!f() { unix2dos $(git lc) ; }; f "
      

      ...واطلاق النار على تحويل الأشياء عن طريق كتابة

      git c2dos
      

Answer 9

لقد قضيت ساعات على التوصل إلى أفضل استخدام ممكن .gitattributes, ، أخيرا أدرك أنني لا يمكن الاعتماد على ذلك.
للأسف طالما JGit المحررين على أساس وجود (والتي لا يمكن التعامل معها .gitattributes بشكل صحيح) ، الحل الآمن هو القوة إذا في كل مكان حتى على محرر المستوى.

استخدام التالية anti-CRLF المطهرات.

• ويندوز/لينكس العملاء: core.autocrlf=input

• ارتكبت .gitattributes: * text=auto eol=lf

• ارتكبت .editorconfig (http://editorconfig.org/) الذي هو نوع من موحد ، جنبا إلى جنب مع محرر الإضافات:

  • https://github.com/editorconfig/
  • https://github.com/welovecoding/editorconfig-netbeans/

--- تحديث 2 ---

على dafaults من بوابة العميل سوف تعمل في معظم الحالات.حتى إذا كان لديك فقط ويندوز فقط العملاء لينكس فقط العملاء أو كليهما.هذه هي:

• ويندوز: core.autocrlf=true يعني تحويل خطوط CRLF على الخروج وتحويل خطوط لو عند إضافة الملفات.
• لينكس: core.autocrlf=input يعني لا تحويل خطوط على الخروج (لا حاجة لأن الملفات من المتوقع أن تكون ملتزمة مع LF) وتحويل خطوط اذا (إذا لزم الأمر) عند إضافة الملفات.

الخاصية يمكن تعيين في نطاقات مختلفة.أود أن أقترح صراحة الإعداد في --global نطاق لتجنب بعض IDE المشكلات الموضحة في نهاية المطاف.

git config core.autocrlf
git config --global core.autocrlf
git config --system core.autocrlf
git config --local core.autocrlf
git config --show-origin core.autocrlf

أيضا أود بشدة تثبيط باستخدام git config --global core.autocrlf false (في حال كان لديك ويندوز فقط عملاء) على عكس ما هو المقترح بوابة الوثائق.تعيين إلى false سوف ارتكاب الملفات مع CRLF في الريبو.ولكن هناك حقا أي سبب.أنت لا تعرف أبدا ما إذا كنت سوف تحتاج إلى مشاركة المشروع مع مستخدمي لينكس.بالاضافة الى انها خطوة إضافية واحدة لكل عميل أن ينضم إلى المشروع بدلا من استخدام الإعدادات الافتراضية.

الآن لبعض الحالات الخاصة من الملفات (على سبيل المثال *.bat *.sh) التي تريد لها أن تكون فحص-مع إن أو مع CRLF يمكنك استخدام .gitattributes

خلاصة القول-حتى بالنسبة لي أفضل الممارسات هو:

• تأكد من أن كل غير ملف ثنائي ارتكب لو على بوابة الريبو (السلوك الافتراضي).
• استخدم هذا الأمر للتأكد من عدم وجود ملفات ملتزمون مع CRLF: git grep -I --files-with-matches --perl-regexp '\r' HEAD (ملاحظة: على عملاء windows يعمل فقط من خلال git-bash و على لينكس العملاء إلا إذا جمعت باستخدام --with-libpcre في ./configure).
• إذا وجدت أي من هذه الملفات عن طريق تنفيذ الأمر أعلاه ، تصحيحها.
• استخدام الحد الأدنى .gitattributes
• إرشاد المستخدمين إلى تعيين core.autocrlf المذكورة أعلاه إلى القيم الافتراضية.
• لا الاعتماد 100% على وجود .gitattributes.بوابة العملاء من ايديس قد تجاهلها أو التعامل معهم differrently.

كما قال بعض الأشياء التي يمكن أن تضاف في بوابة سمات:

# Always checkout with LF
*.sh            text eol=lf
# Always checkout with CRLF
*.bat           text eol=crlf

أعتقد أن بعض الآمنة الأخرى خيارات .gitattributes بدلا من استخدام الكشف التلقائي عن الملفات الثنائية:

• -text (هـ.g *.zip أو *.jpg الملفات:لن يعامل النص.وبالتالي لا يوجد خط نهاية التحويلات ستتم محاولة.مهرجان دبي السينمائي الدولي قد يكون ممكنا من خلال برامج التحويل)
• text !eol (مثلا ، بالنسبة *.java,*.html:يعامل النص ، ولكن eol أسلوب التفضيل لم يتم تعيين.لذلك العميل يستخدم إعداد.)
• -text -diff -merge (هـ.g *.hugefile:لا يعامل النص.لا فرق/دمج ممكن)

--- التحديث السابق ---

واحد مؤلمة سبيل المثال العميل سوف ارتكاب الملفات بشكل خاطئ:

netbeans 8.2 (في ويندوز) ، خطأ ارتكاب جميع الملفات النصية مع CRLFs ، ما لم لديك صراحة مجموعة core.autocrlf العالمية.وهذا يتناقض مع معيار بوابة سلوك العملاء و يسبب الكثير من المشاكل في وقت لاحق ، في حين تحديث/دمج.هذا هو ما يجعل بعض تظهر ملفات مختلفة (على الرغم من أنها ليست) حتى عندما تعود.
نفس السلوك في netbeans يحدث حتى إذا كان لديك إضافة الصحيح .gitattributes إلى المشروع الخاص بك.

باستخدام الأمر التالي بعد ارتكابها ، على الأقل سوف تساعدك على الكشف المبكر سواء بوابة الريبو لديه خط إنهاء القضايا: git grep -I --files-with-matches --perl-regexp '\r' HEAD