git แทนที่ LF ด้วย CRLF

ใช้งานคอมไพล์บนเครื่อง Windows XP โดยใช้ bash ฉันส่งออกโครงการของฉันจาก SVN แล้วโคลนที่เก็บข้อมูลเปลือย

จากนั้นฉันวางการส่งออกไปยังไดเรกทอรีที่เก็บเปลือยและทำ:

git add -A

ฉันได้รับข้อความว่า:

LF จะถูกแทนที่ด้วย CRLF

อะไรคือการเปลี่ยนแปลงของการแปลงนี้ นี่คือโซลูชัน. NET ใน Visual Studio

ข้อความเหล่านี้เกิดจากค่าเริ่มต้นที่ไม่ถูกต้องของcore.autocrlfบน Windows

แนวคิดของautocrlfคือการจัดการการแปลงปลายสายอย่างโปร่งใส และมันก็เป็นเช่นนั้น!

ข่าวร้าย : ต้องกำหนดค่าด้วยตนเอง
ข่าวดี : มันควรจะทำเพียงครั้งเดียวต่อการติดตั้งคอมไพล์ (ต่อการตั้งค่าโครงการก็เป็นไปได้)

วิธีautocrlfการทำงาน :

core.autocrlf=true:      core.autocrlf=input:     core.autocrlf=false:

        repo                     repo                     repo
      ^      V                 ^      V                 ^      V
     /        \               /        \               /        \
crlf->lf    lf->crlf     crlf->lf       \             /          \      
   /            \           /            \           /            \

ที่นี่crlf= เครื่องหมายระบุจุดสิ้นสุดของรูปแบบ win-style lf= unix-style (และ mac osx)

(pre-osx crไม่ได้รับผลกระทบใด ๆ จากสามตัวเลือกด้านบน)

คำเตือนนี้ปรากฏขึ้นเมื่อใด (ใต้ Windows)

    - autocrlf= trueถ้าคุณมีรูปแบบยูนิกซ์lfในไฟล์ใดไฟล์หนึ่งของคุณ (= RARELY)
    - autocrlf= inputหากคุณมีรูปแบบวินเป็นcrlfหนึ่งในไฟล์ของคุณ (= เกือบตลอดเวลา)
    - autocrlf= false- ไม่เคย!

คำเตือนนี้หมายถึงอะไร

คำเตือน " LF จะถูกแทนที่ด้วย CRLF " บอกว่าคุณ (มีautocrlf= true) จะสูญเสีย LF ในยูนิกซ์สไตล์ของคุณหลังจากเสร็จสิ้นการชำระเงิน (มันจะถูกแทนที่ด้วย CRLF สไตล์ Windows) Git ไม่ได้คาดหวังให้คุณใช้ LF แบบ unix ในหน้าต่าง

คำเตือน " CRLF จะถูกแทนที่ด้วย LF " บอกว่าคุณ (มีautocrlf= input) จะสูญเสีย CRLF สไตล์หน้าต่างของคุณหลังจากรอบการยอมรับการชำระเงิน (มันจะถูกแทนที่ด้วย LF สไตล์ unix) อย่าใช้ในinputหน้าต่าง

อีกวิธีหนึ่งในการแสดงว่าautocrlfทำงานอย่างไร

1) true:             x -> LF -> CRLF
2) input:            x -> LF -> LF
3) false:            x -> x -> x

โดยที่xคือ CRLF (windows-style) หรือ LF (unix-style) และลูกศรหมายถึง

file to commit -> repository -> checked out file

วิธีแก้ไข

เลือกค่าเริ่มต้นสำหรับcore.autocrlfระหว่างการติดตั้ง git และเก็บไว้ใน gitconfig ( %ProgramFiles(x86)%\git\etc\gitconfig) ทั้งระบบ ยังมี (เรียงตามลำดับต่อไปนี้):

   - "ทั่วโลก" (ต่อผู้ใช้) ตั้งอยู่ที่ gitconfig ~/.gitconfigยังอีก
   - "ทั่วโลก" gitconfig (ต่อผู้ใช้) ที่$XDG_CONFIG_HOME/git/configหรือ$HOME/.config/git/configและ
   - "ท้องถิ่น" (ต่อ repo) gitconfig ที่.git/configใน dir ทำงาน

ดังนั้นเขียนgit config core.autocrlfใน dir ทำงานเพื่อตรวจสอบค่าที่ใช้ในปัจจุบันและ

   - เพิ่มautocrlf=falseไปยังระบบ gitconfig # ต่อโซลูชันระบบ
   - git config --global core.autocrlf false            # โซลูชั่นต่อผู้ใช้
   - git config --local core.autocrlf false              # โซลูชั่นต่อโครงการ

คำเตือน
- git configการตั้งค่าสามารถแทนที่ได้ด้วยgitattributesการตั้งค่า
- crlf -> lfการแปลงจะเกิดขึ้นเมื่อเพิ่มไฟล์ใหม่ไฟล์crlfที่มีอยู่แล้วใน repo จะไม่ได้รับผลกระทบ

คุณธรรม (สำหรับ Windows):
    - ใช้core.autocrlf= trueถ้าคุณวางแผนที่จะใช้โครงการนี้ภายใต้ระบบปฏิบัติการยูนิกซ์เช่นกัน (และไม่เต็มใจที่จะกำหนดค่าเครื่องมือแก้ไข / IDE ของคุณให้ใช้ปลายสายยูนิกซ์)
    - ใช้core.autocrlf= falseถ้าคุณวางแผนที่จะใช้โครงการนี้ใน Windows เท่านั้น ( หรือคุณได้กำหนดค่าเครื่องมือแก้ไข / IDE ของคุณให้ใช้จุดสิ้นสุดบรรทัด unix)
    - ห้ามใช้core.autocrlf= inputเว้นแต่คุณจะมีเหตุผลที่ดีในการ ( เช่นถ้าคุณใช้ยูทิลิตี unix ใน windows หรือหากคุณพบปัญหาเกี่ยวกับ makefiles)

PS มีอะไรให้เลือกบ้างเมื่อติดตั้ง git สำหรับ Windows
หากคุณจะไม่ใช้โครงการใด ๆ ภายใต้ระบบปฏิบัติการยูนิกซ์อย่าเห็นด้วยกับตัวเลือกแรกที่เป็นค่าเริ่มต้น เลือกรายการที่สาม ( ชำระเงินตามสภาพ, กระทำตามสภาพ ) คุณจะไม่เห็นข้อความนี้ เคย

ความชอบส่วนบุคคล PPS ของฉันคือการกำหนดค่าบรรณาธิการ / IDEใช้ปลาย Unix สไตล์และการตั้งค่าไปcore.autocrlffalse

Git มีสามโหมดว่าจะจัดการกับการสิ้นสุดบรรทัดอย่างไร:

$ git config core.autocrlf
# that command will print "true" or "false" or "input"

คุณสามารถตั้งค่าโหมดที่จะใช้โดยการเพิ่มพารามิเตอร์เพิ่มเติมtrueหรือfalseไปยังบรรทัดคำสั่งด้านบน

หากcore.autocrlfตั้งค่าเป็นจริงนั่นหมายความว่าเมื่อใดก็ตามที่คุณเพิ่มไฟล์ลงใน git repo ที่ git คิดว่าเป็นไฟล์ข้อความมันจะเปลี่ยนปลายสาย CRLF ทั้งหมดเป็นเพียง LF ก่อนที่มันจะเก็บไว้ในการกระทำ เมื่อใดก็ตามที่คุณทำgit checkoutสิ่งใดไฟล์ข้อความทั้งหมดจะมีการแปลงตอนจบบรรทัด LF เป็นตอนจบ CRLF สิ่งนี้ช่วยให้การพัฒนาโครงการข้ามแพลตฟอร์มที่ใช้รูปแบบการสิ้นสุดบรรทัดที่แตกต่างกันโดยไม่ต้องทำเสียงดังมากเพราะบรรณาธิการแต่ละคนจะเปลี่ยนรูปแบบการสิ้นสุดของบรรทัด

ผลข้างเคียงของการแปลงที่สะดวกนี้และนี่คือสิ่งที่คำเตือนที่คุณเห็นเป็นเรื่องเกี่ยวกับว่าถ้าไฟล์ข้อความที่คุณประพันธ์มีตอนจบ LF แทน CRLF มันจะถูกเก็บไว้กับ LF ตามปกติ แต่เมื่อตรวจสอบแล้ว ออกมาภายหลังจะมีตอนจบ CRLF สำหรับไฟล์ข้อความปกตินี่เป็นเรื่องปกติ คำเตือนคือ "สำหรับข้อมูลของคุณ" ในกรณีนี้ แต่ในกรณีที่คอมไพล์ประเมินไฟล์ไบนารี่ไม่ถูกต้องให้เป็นไฟล์ข้อความคำเตือนที่สำคัญเพราะคอมไพล์จะทำให้ไฟล์ไบนารีของคุณเสียหาย

หากcore.autocrlfตั้งค่าเป็นเท็จจะไม่มีการแปลงบรรทัดสิ้นสุดดังนั้นไฟล์ข้อความจะถูกตรวจสอบตามสภาพ โดยปกติแล้วจะใช้ได้ดีตราบใดที่นักพัฒนาซอฟต์แวร์ของคุณทั้งบน Linux หรือบน Windows แต่จากประสบการณ์ของฉันฉันยังคงมีแนวโน้มที่จะได้รับไฟล์ข้อความที่ลงท้ายด้วยเส้นผสมที่ท้ายทำให้เกิดปัญหา

การตั้งค่าส่วนตัวของฉันคือการเปิดการตั้งค่าไว้ในฐานะนักพัฒนา Windows

ดูhttp://kernel.org/pub/software/scm/git/docs/git-config.htmlสำหรับข้อมูลที่อัปเดตซึ่งมีค่า "อินพุต"

หากคุณตรวจสอบรหัสแล้วไฟล์จะถูกทำดัชนีแล้ว หลังจากเปลี่ยนการตั้งค่าคอมไพล์แล้วให้พูดโดยเรียกใช้:

git config --global core.autocrlf input 

คุณควรรีเฟรชดัชนีด้วย

git rm --cached -r . 

และเขียนดัชนีคอมไพล์อีกครั้งด้วย

git reset --hard

https://help.github.com/articles/dealing-with-line-endings/#refreshing-a-repository-after-changing-line-endings

หมายเหตุ: นี่จะเป็นการลบการเปลี่ยนแปลงในเครื่องของคุณให้พิจารณาการลบทิ้งก่อนที่คุณจะทำสิ่งนี้

git config core.autocrlf false

ทั้งunix2dosและdos2unixมีอยู่ใน windows ด้วย gitbash คุณสามารถใช้คำสั่งต่อไปนี้เพื่อทำการแปลง UNIX (LF) -> DOS (CRLF) ดังนั้นคุณจะไม่ได้รับคำเตือน

unix2dos filename

หรือ

dos2unix -D filename

แต่อย่ารันคำสั่งนี้กับไฟล์ CRLF ใด ๆ ที่มีอยู่จากนั้นคุณจะได้รับบรรทัดใหม่ที่ว่างเปล่าทุกบรรทัดที่สอง

dos2unix -D filenameจะไม่ทำงานกับทุกระบบปฏิบัติการ กรุณาตรวจสอบลิงค์นี้เพื่อความเข้ากันได้

--forceหากมีเหตุผลบางอย่างที่คุณจะต้องบังคับคำสั่งแล้วใช้ -fหากจะกล่าวว่าการใช้งานที่ไม่ถูกต้องแล้ว

ฉันคิดว่าคำตอบของ @ Basiloungas ใกล้เคียง แต่ล้าสมัย (อย่างน้อยบน Mac)

เปิดไฟล์ ~ / .gitconfig และตั้งค่าsafecrlfเป็นเท็จ

[core]
       autocrlf = input
       safecrlf = false

นั่นจะทำให้มันไม่สนใจจุดจบของบรรทัด (เห็นได้ชัดว่าเหมาะสำหรับฉัน)

บทความ GitHub บนปลายสายเป็นที่กล่าวถึงกันทั่วไปเมื่อพูดคุยเกี่ยวกับหัวข้อนี้

ประสบการณ์ส่วนตัวของฉันเกี่ยวกับการใช้การcore.autocrlfตั้งค่าการตั้งค่าที่แนะนำบ่อย ๆนั้นหลากหลายมาก

ฉันใช้ Windows กับ Cygwin ซึ่งเกี่ยวข้องกับโครงการ Windows และ UNIX ในเวลาที่ต่างกัน แม้แต่โครงการ Windows ของฉันบางครั้งก็ใช้bashเชลล์สคริปต์ซึ่งต้องการจุดสิ้นสุดบรรทัด UNIX (LF)

ใช้การcore.autocrlfตั้งค่าที่แนะนำของ GitHub สำหรับ Windows ถ้าฉันดูโครงการ UNIX (ซึ่งทำงานได้อย่างสมบูรณ์บน Cygwin - หรือบางทีฉันมีส่วนร่วมในโครงการที่ฉันใช้บนเซิร์ฟเวอร์ Linux) ไฟล์ข้อความจะถูกตรวจสอบด้วย Windows (CRLF ) การสิ้นสุดบรรทัดสร้างปัญหา

โดยพื้นฐานแล้วสำหรับสภาพแวดล้อมแบบผสมอย่างที่ฉันมีการตั้งค่าโกลบอลcore.autocrlfเป็นตัวเลือกใด ๆ จะไม่ทำงานได้ดีในบางกรณี ตัวเลือกนี้อาจถูกตั้งค่าบนการกำหนดค่า git ในพื้นที่ (ที่เก็บ) แต่ก็ไม่ดีพอสำหรับโครงการที่มีทั้งที่เกี่ยวข้องกับ Windows และ UNIX (เช่นฉันมีโครงการ Windows ที่มีbashสคริปต์อรรถประโยชน์บางตัว)

ตัวเลือกที่ดีที่สุดที่ฉันพบคือการสร้างไฟล์. gitattributesต่อที่เก็บ บทความ GitHubกล่าวถึงมัน
ตัวอย่างจากบทความนั้น:

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

# Explicitly declare text files you want to always be normalized and converted
# to native line endings on checkout.
*.c text
*.h text

# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf

# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary

ในที่เก็บโครงการหนึ่งของฉัน:

* text=auto

*.txt         text eol=lf
*.xml         text eol=lf
*.json        text eol=lf
*.properties  text eol=lf
*.conf        text eol=lf

*.awk  text eol=lf
*.sed  text eol=lf
*.sh   text eol=lf

*.png  binary
*.jpg  binary

*.p12  binary

การตั้งค่าเป็นเรื่องเล็ก ๆ น้อย ๆ แต่ทำครั้งเดียวต่อโครงการและผู้มีส่วนร่วมในระบบปฏิบัติการใด ๆ ไม่ควรมีปัญหากับการสิ้นสุดบรรทัดเมื่อทำงานกับโครงการนี้

ในกลุ่มให้เปิดไฟล์ (เช่น:) :e YOURFILEENTERจากนั้น

:set noendofline binary
:wq

ฉันมีปัญหานี้เช่นกัน

SVN ไม่ได้ทำการแปลงบรรทัดสิ้นสุดดังนั้นไฟล์จะถูกคอมมิชชันด้วยการสิ้นสุดบรรทัด CRLF เหมือนเดิม หากคุณใช้ git-svn เพื่อใส่โครงการเข้าไปใน git แล้ว CRLF endings จะยังคงอยู่ในที่เก็บ git ซึ่งไม่ใช่สถานะ git ที่คาดว่าจะพบตัวเอง - ค่าเริ่มต้นคือมีเพียงปลายสาย unix / linux (LF) ตรวจสอบใน.

เมื่อคุณตรวจสอบไฟล์บน windows การแปลง autocrlf จะทำให้ไฟล์ไม่เสียหาย (เนื่องจากมีจุดสิ้นสุดที่ถูกต้องสำหรับแพลตฟอร์มปัจจุบัน) อย่างไรก็ตามกระบวนการที่ตัดสินใจว่ามีความแตกต่างกับไฟล์ที่เช็คอินหรือไม่นั้นทำการแปลงแบบย้อนกลับก่อนที่จะเปรียบเทียบผลลัพธ์ในการเปรียบเทียบสิ่งที่คิดว่าเป็น LF ในไฟล์ที่เช็กเอาต์ด้วย CRLF ที่ไม่คาดคิดในที่เก็บ

เท่าที่ฉันเห็นตัวเลือกของคุณคือ:

1. นำเข้ารหัสของคุณอีกครั้งในที่เก็บ git ใหม่โดยไม่ต้องใช้ git-svn นี่จะหมายถึงการสิ้นสุดบรรทัดจะถูกแปลงใน intial git คอมมิท - ทั้งหมด
2. ตั้งค่า autocrlf เป็น false และไม่สนใจข้อเท็จจริงที่ว่าการสิ้นสุดบรรทัดนั้นไม่ได้อยู่ในรูปแบบที่ต้องการ
3. ลองตรวจสอบไฟล์ของคุณด้วยการปิด autocrlf แก้ไขการสิ้นสุดบรรทัดทั้งหมดตรวจสอบทุกอย่างกลับมาแล้วเปิดใหม่อีกครั้ง
4. เขียนประวัติพื้นที่เก็บข้อมูลของคุณเพื่อให้การกระทำดั้งเดิมไม่มี CRLF ที่ไม่ได้คาดหวัง (คำเตือนทั่วไปเกี่ยวกับการเขียนประวัติใหม่นำไปใช้)

เชิงอรรถ:หากคุณเลือกตัวเลือก # 2 ประสบการณ์ของฉันคือเครื่องมือเสริมบางอย่าง (rebase, patch และอื่น ๆ ) ไม่รองรับไฟล์ CRLF และคุณจะจบลงด้วยไฟล์ที่มี CRLF และ LF (เส้นที่ไม่สอดคล้องกัน) ตอนจบ) ฉันรู้ว่าไม่มีทางที่จะทำให้ดีที่สุดทั้งสองอย่าง

การลบด้านล่างออกจากไฟล์ ~ / .gitattributes

* text=auto

จะป้องกันไม่ให้คอมไพล์ตรวจสอบการสิ้นสุดบรรทัดในครั้งแรก

คุณควรอ่าน:

คำเตือน: ( ถ้าคุณตรวจสอบ / หรือโคลนไปยังโฟลเดอร์อื่นด้วย core.autocrlf ปัจจุบันของคุณtrue ) LF จะถูกแทนที่ด้วย CRLF

ไฟล์จะมีการสิ้นสุดบรรทัดต้นฉบับในไดเรกทอรีทำงาน( ปัจจุบัน ) ของคุณ

ภาพนี้ควรอธิบายความหมายของมัน

http://www.rtuin.nl/2013/02/how-to-make-git-ignore-different-line-endings/

echo "* -crlf" > .gitattributes 

ทำสิ่งนี้ในคอมมิทคอมมิตหรือคอมไพล์อาจยังเห็นไฟล์ทั้งหมดตามที่ถูกแก้ไขเมื่อคุณทำการเปลี่ยนแปลงครั้งเดียว (ขึ้นอยู่กับว่าคุณได้เปลี่ยนตัวเลือก autocrlf แล้ว)

อันนี้ใช้งานได้จริง Git จะเคารพการสิ้นสุดของบรรทัดในโปรเจ็กต์การสิ้นสุดบรรทัดแบบผสมและไม่เตือนคุณเกี่ยวกับพวกเขา

ฉันไม่ค่อยรู้เรื่อง git บน Windows แต่ ...

ปรากฏว่าฉัน git กำลังแปลงรูปแบบการส่งคืนเพื่อให้ตรงกับแพลตฟอร์มที่ใช้งานอยู่ (Windows) CRLF เป็นรูปแบบผลตอบแทนเริ่มต้นใน Windows ในขณะที่ LF เป็นรูปแบบผลตอบแทนเริ่มต้นสำหรับ OS อื่น ๆ ส่วนใหญ่

โอกาสที่รูปแบบการส่งคืนจะถูกปรับอย่างเหมาะสมเมื่อรหัสถูกย้ายไปยังระบบอื่น ฉันคิดว่าคอมไพล์ฉลาดพอที่จะทำให้ไฟล์ไบนารีไม่เสียหายแทนที่จะพยายามแปลง LF เป็น CRLF ใน JPEG

โดยสรุปคุณอาจไม่ต้องกังวลกับการแปลงนี้มากเกินไป อย่างไรก็ตามถ้าคุณไปที่เก็บโครงการของคุณเป็น tarball เพื่อนโค้ดน่าจะขอบคุณที่มี LF Terminator มากกว่า CRLF ขึ้นอยู่กับว่าคุณสนใจมากแค่ไหน (และขึ้นอยู่กับว่าคุณไม่ได้ใช้ Notepad) คุณอาจต้องการตั้งค่า git ให้ใช้ LF return ถ้าทำได้ :)

ภาคผนวก: CR คือรหัส ASCII 13, LF คือรหัส ASCII 10 ดังนั้น CRLF คือสองไบต์ในขณะที่ LF เป็นหนึ่ง

ตรวจสอบให้แน่ใจว่าคุณได้ติดตั้ง git ล่าสุดแล้ว
ฉันทำตามข้างต้นgit config core.autocrlf falseเมื่อใช้ git (รุ่น 2.7.1) แต่มันใช้งานไม่ได้
จากนั้นจะทำงานตอนนี้เมื่ออัปเกรดคอมไพล์ (จาก 2.7.1 เป็น 2.20.1)

1. เปิดไฟล์ใน Notepad ++
2. ไปที่การแก้ไข / การแปลง EOL
3. คลิกที่รูปแบบ Windows
4. บันทึกไฟล์

คำถามของ OP เกี่ยวข้องกับ windows และฉันไม่สามารถใช้งานอื่น ๆ ได้โดยไม่ต้องไปที่ไดเรกทอรีหรือแม้แต่เรียกใช้ไฟล์ใน Notepad ++ เนื่องจากผู้ดูแลระบบไม่ทำงาน .. ดังนั้นต้องไปที่เส้นทางนี้:

C:\Program Files (x86)\Git\etc>git config --global core.autocrlf false

เครื่องมือแก้ไขข้อความจำนวนมากอนุญาตให้คุณเปลี่ยนได้LFดูคำแนะนำ Atom ด้านล่าง ง่ายและชัดเจน

คลิกCRLFที่ด้านล่างขวา:

เลือกLFแบบเลื่อนลงด้านบน:

ในพรอมต์ GNU / Linux เชลล์คำสั่ง dos2unix & unix2dos ช่วยให้คุณสามารถแปลง / จัดรูปแบบไฟล์ที่มาจาก MS Windows ได้อย่างง่ายดาย

CRLF อาจทำให้เกิดปัญหาขณะใช้ "รหัส" ของคุณในสองระบบปฏิบัติการที่แตกต่างกัน (Linux และ Windows) สคริปต์ python ของฉันถูกเขียนในคอนเทนเนอร์ dock dock ของ Linux จากนั้นดันโดยใช้ Windows git-bash มันเตือนฉันว่า LF จะถูกแทนที่ด้วย CRLF ผมไม่ได้ให้มันมีความคิด /usr/bin/env: 'python\r': No such file or directoryแต่แล้วเมื่อผมเริ่มสคริปต์ต่อมาก็กล่าวว่า ตอนนี้\rสำหรับ ramification สำหรับคุณ Windows ใช้ "CR" - กลับรถ - ด้านบนของ '\ n' เป็นตัวอักษรบรรทัดใหม่ \n\r- นั่นคือสิ่งที่คุณอาจต้องพิจารณา

เครื่องมือส่วนใหญ่ใน Windows ยอมรับเฉพาะ LF ในไฟล์ข้อความ ตัวอย่างเช่นคุณสามารถควบคุมพฤติกรรมของ Visual Studio ในไฟล์ชื่อ '. editorconfig' ด้วยเนื้อหาตัวอย่าง (ส่วนหนึ่ง) ดังต่อไปนี้:

 indent_style = space
 indent_size = 2
 end_of_line = lf    <<====
 charset = utf-8

เฉพาะ Windows-Notepad ดั้งเดิมเท่านั้นที่ใช้ไม่ได้กับ LF แต่มีเครื่องมือแก้ไขอย่างง่าย ๆ ที่เหมาะสมกว่านี้!

ดังนั้นคุณควรใช้ LF ในไฟล์ข้อความใน Windows ด้วย นี่คือข้อความของฉันแนะนำ! ไม่มีเหตุผลที่จะใช้ CRLF ใน windows!

(การสนทนาเดียวกันนั้นใช้ \ in include path ใน C / ++ มันเป็นเรื่องโกหกใช้ #include <pathTo / myheader.h> ด้วยเครื่องหมายทับ! ซึ่งเป็นมาตรฐาน C / ++ และคอมไพเลอร์ของ Microsoft ทั้งหมดสนับสนุน)

ดังนั้นการตั้งค่าที่เหมาะสมสำหรับคอมไพล์คือ

git config core.autocrlf false

ข้อความของฉัน: ลืมโปรแกรมการคิดแบบเดิม ๆ เช่น dos2unix และ unix2dos ชี้แจงในทีมของคุณว่า LF เหมาะสมที่จะใช้ใน Windows