ทำไมฉันถึงควรใช้ core.autocrlf = true ใน Git

ฉันมีที่เก็บ Git ที่สามารถเข้าถึงได้จากทั้ง Windows และ OS X และฉันรู้ว่ามีไฟล์บางไฟล์ที่มี CRLF line-endings เท่าที่ฉันสามารถบอกได้มีสองวิธีในการจัดการกับเรื่องนี้:

1. ตั้งcore.autocrlfไปfalseทุกที่

2. ทำตามคำแนะนำที่นี่ (echoed บนหน้าความช่วยเหลือของ GitHub) เพื่อแปลงพื้นที่เก็บข้อมูลให้มีเฉพาะจุดสิ้นสุด LF และหลังจากนั้นตั้งcore.autocrlfเป็นtrueWindows และinputOS X ปัญหาในการทำเช่นนี้คือถ้าฉันมีไฟล์ไบนารีใด ๆ ในที่เก็บ ที่:

   1. ทำเครื่องหมายไม่ถูกต้องว่าเป็นไบนารีใน gitattributes และ
   2. มีทั้ง CRLF และ LF

   พวกเขาจะเสียหาย เป็นไปได้ว่าที่เก็บของฉันมีไฟล์ดังกล่าว

เหตุใดฉันจึงไม่ควรปิดการแปลงตอนจบของ Git มีคำเตือนที่คลุมเครือบนเว็บจำนวนมากเกี่ยวกับการcore.autocrlfปิดสวิตช์ที่ก่อให้เกิดปัญหา แต่มีน้อยมากโดยเฉพาะคน; สิ่งเดียวที่ฉันได้พบจนถึงขณะนี้คือ kdiff3 ไม่สามารถจัดการกับตอนจบ CRLF (ไม่ใช่ปัญหาสำหรับฉัน) และตัวแก้ไขข้อความบางรายการมีปัญหาในการสิ้นสุดบรรทัด (เช่นกันไม่ใช่ปัญหาสำหรับฉัน)

ที่เก็บอยู่ภายใน บริษัท ของฉันดังนั้นฉันไม่ต้องกังวลเกี่ยวกับการแบ่งปันกับผู้ที่มีการตั้งค่า autocrlf หรือข้อกำหนดการสิ้นสุดบรรทัดต่าง ๆ

มีปัญหาอื่นอีกหรือไม่ที่เพิ่งออกจากสายงานตอนจบตามที่ฉันไม่รู้?

เหตุผลเฉพาะที่กำหนดautocrlfให้trueเป็น:

• หลีกเลี่ยงการgit statusแสดงไฟล์ทั้งหมดของคุณmodifiedเนื่องจากการแปลง EOL อัตโนมัติเสร็จสิ้นเมื่อทำการโคลน repo EOL Git ที่ใช้ Unix บน Windows หนึ่ง (ดูที่ปัญหา 83เป็นต้น)
• และเครื่องมือการเข้ารหัสของคุณอย่างใดขึ้นอยู่กับพื้นเมืองสไตล์ EOL เป็นอยู่ในปัจจุบันในไฟล์ของคุณ:
  • ตัวอย่างเช่นตัวสร้างโค้ดใช้รหัสในการตรวจจับ EOL ดั้งเดิม
  • ชุดภายนอกอื่น ๆ (ภายนอก repo ของคุณ) ด้วย regexp หรือชุดรหัสเพื่อตรวจหา EOL ดั้งเดิม
  • ฉันเชื่อว่าปลั๊กอิน Eclipse บางอย่างสามารถสร้างไฟล์ด้วย CRLF โดยไม่คำนึงถึงแพลตฟอร์มซึ่งอาจเป็นปัญหาได้
  • คุณใช้รหัสกับ Notepad.exe ( เว้นแต่ว่าคุณกำลังใช้ Windows 10 2018.09+ โดยที่ Notepad ตรวจพบอักขระ EOL )

จนกว่าคุณจะสามารถเห็นการรักษาที่เฉพาะเจาะจงที่จะต้องจัดการกับ EOL พื้นเมืองคุณจะดีกว่าออกautocrlfไปfalse (git config --global core.autocrlf false )

โปรดทราบว่าการกำหนดค่านี้จะเป็นท้องถิ่น (เนื่องจากการกำหนดค่าไม่ได้ถูกส่งจาก repo เป็น repo)

หากคุณต้องการกำหนดค่าเดียวกันสำหรับผู้ใช้ทั้งหมดที่คัดลอก repo นั้นลองดู " กลยุทธ์การจัดการที่ดีที่สุดCRLFกับ git คืออะไร " โดยใช้textแอตทริบิวต์ใน.gitattributesไฟล์ไฟล์

ตัวอย่าง:

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

หมายเหตุ: การเริ่มต้นคอมไพล์ 2.8 (มีนาคม 2559) เครื่องหมายการรวมจะไม่แนะนำการลงท้ายด้วยเส้นผสม (LF) ในไฟล์ CRLF อีกต่อไป
ดูที่ " ทำให้ Git ใช้ CRLF ใน" <<<<<<< HEAD "รวมบรรทัด "

ฉันเป็นผู้พัฒนา. NET และใช้ Git และ Visual Studio มาหลายปี คำแนะนำที่แข็งแกร่งของฉันคือตั้งค่าการจบบรรทัดเป็นจริง และทำมันให้เร็วที่สุดเท่าที่จะทำได้ในช่วงชีวิตของ Repository ของคุณ

ที่ถูกกล่าวว่าฉันเกลียดที่ Git เปลี่ยนจุดสิ้นสุดของฉัน การควบคุมแหล่งที่มาควรบันทึกและดึงงานที่ฉันทำเท่านั้นไม่ควรแก้ไข เคย. แต่มันก็เป็นเช่นนั้น

จะเกิดอะไรขึ้นหากคุณไม่ได้ตั้งค่าให้นักพัฒนาทุกคนตั้งค่าเป็นจริงในที่สุดหนึ่งนักพัฒนาจะตั้งค่าเป็นจริง สิ่งนี้จะเริ่มเปลี่ยนการสิ้นสุดบรรทัดของไฟล์ทั้งหมดเป็น LF ใน repo ของคุณ และเมื่อผู้ใช้ตั้งค่าเป็นเท็จตรวจสอบสิ่งเหล่านั้น Visual Studio จะเตือนคุณและขอให้คุณเปลี่ยนพวกเขา คุณจะมี 2 สิ่งเกิดขึ้นอย่างรวดเร็ว หนึ่งคุณจะได้รับคำเตือนมากขึ้นเรื่อย ๆ ทีมของคุณก็จะยิ่งได้รับมากขึ้นเท่านั้น สิ่งที่สองและที่แย่กว่านั้นคือมันจะแสดงให้เห็นว่าทุกบรรทัดของทุกไฟล์ที่ถูกแก้ไขเปลี่ยนแปลงไป (เพราะตอนจบของทุกบรรทัดจะถูกเปลี่ยนโดยคนจริง) ในที่สุดคุณจะไม่สามารถติดตามการเปลี่ยนแปลงใน repo ของคุณได้อย่างน่าเชื่อถืออีกต่อไป มันง่ายกว่าและสะอาดกว่าที่จะทำให้ทุกคนกลายเป็นจริงมากกว่าที่จะพยายามทำให้ทุกคนเป็นเท็จ น่ากลัวอย่างที่ต้องอยู่กับความจริงที่ว่าแหล่งข้อมูลที่เชื่อถือได้ของคุณกำลังทำสิ่งที่ไม่ควรทำ เคย.

อัปเดต 2 :

Xcode 9 ดูเหมือนจะมี "คุณสมบัติ" ซึ่งจะไม่สนใจการสิ้นสุดบรรทัดปัจจุบันของไฟล์และเพียงแค่ใช้การตั้งค่าการสิ้นสุดบรรทัดเริ่มต้นของคุณเมื่อแทรกบรรทัดลงในไฟล์ทำให้เกิดไฟล์ที่มีจุดสิ้นสุดของเส้นผสม

ฉันค่อนข้างมั่นใจว่าข้อผิดพลาดนี้ไม่มีอยู่ใน Xcode 7 ไม่แน่ใจเกี่ยวกับ Xcode 8 ข่าวดีก็คือว่ามันได้รับการแก้ไขใน Xcode 10

สำหรับเวลาที่มีอยู่ข้อผิดพลาดนี้ทำให้เกิดความฮือฮาเล็กน้อยใน codebase ที่ฉันอ้างถึงในคำถาม (ซึ่งทุกวันนี้ใช้autocrlf=false) และนำไปสู่ข้อความ "EOL" หลายข้อความและในที่สุดฉันก็เขียน git pre-commithook เพื่อตรวจสอบ สำหรับ / ป้องกันการแนะนำการสิ้นสุดของบรรทัดแบบผสม

อัปเดต :

หมายเหตุ: เท่าที่สังเกตจาก VonC เริ่มต้นจาก Git 2.8 เครื่องหมายผสานจะไม่แนะนำ Unix สไตล์สายลงท้ายไฟล์

ต้นฉบับ :

อาการสะอึกเล็กน้อยที่ฉันได้สังเกตเห็นด้วยการตั้งค่านี้คือเมื่อมีการรวมความขัดแย้งบรรทัด git เพิ่มเพื่อทำเครื่องหมายความแตกต่างไม่มีจุดสิ้นสุดบรรทัด Windows แม้เมื่อส่วนที่เหลือของไฟล์ทำและคุณสามารถท้าย กับไฟล์ที่มีจุดสิ้นสุดของบรรทัดแบบผสมเช่น:

// 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เพื่อดูการเปลี่ยนแปลงไฟล์ที่มีการสิ้นสุดบรรทัด Windows บรรทัดที่ถูกเพิ่มจะแสดงการขึ้นบรรทัดใหม่ดังนั้น:

    // Not changed

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

_{* มันไม่ได้ทำบุญจริงๆ: "ปัญหา"}