วิธีแก้ไขข้อความ“ Hunk # 1 FAILED ที่ 1 (สิ้นสุดบรรทัดที่แตกต่างกัน)”


22

ฉันพยายามสร้างแพตช์ด้วยคำสั่ง

git diff sourcefile >/var/lib/laymab/overlay/category/ebuild/files/thepatch.patch

เมื่อฉันใช้แพทช์มันให้ฉัน

$ patch -v
GNU patch 2.7.5

$ /usr/bin/patch -p1 </var/lib/laymab/overlay/category/ebuild/files/thepatch.patch
patching file sourcefile
Hunk #1 FAILED at 1 (different line endings).
Hunk #2 FAILED at 23 (different line endings).
Hunk #3 FAILED at 47 (different line endings).
Hunk #4 FAILED at 65 (different line endings).
Hunk #5 FAILED at 361 (different line endings).
5 out of 5 hunks FAILED -- saving rejects to file sourcefile.rej

ฉันพยายามใช้ dos2unix กับทั้งไฟล์ src และไฟล์แก้ไข แต่ข้อความไม่หายไป ...

UPD: - ละเลยช่องว่างไม่ได้ช่วยเกินไป

PATCH COMMAND:  patch -p1 -g0 -E --no-backup-if-mismatch --ignore-whitespace --dry-run -f < '/var/lib/layman/dotnet/dev-dotnet/slntools/files/remove-wix-project-from-sln-file-v2.patch'

=====================================================
checking file Main/SLNTools.sln
Hunk #1 FAILED at 14 (different line endings).
Hunk #2 FAILED at 49 (different line endings).
Hunk #3 FAILED at 69 (different line endings).
Hunk #4 FAILED at 102 (different line endings).
4 out of 4 hunks FAILED

UPD: พบบทความที่ดีมาก: /programming//a/4425433/1709408


ลอง sed -i.bak -e 's/\r$//g' somethingดู ฉันไม่คิดว่า dos2unix จะจัดการกับ end-of-line แบบผสมอย่างที่คุณต้องการ
Arthur2e5

ความชั่วร้ายทันที หากคุณมีโปรแกรมปะต่อที่มีจุดสิ้นสุด CF-LF เช่นเดียวกับไฟล์มันจะตัด CR จากโปรแกรมปะแก้ของคุณอย่างมีความสุขจากนั้นให้ใส่แบบที่ปลายสาย (ซึ่งเพิ่งแตก) ไม่เหมาะ
เอสเอฟ

คำตอบ:


5

ฉันมีปัญหาเดียวกันกับการใช้patchคำสั่งที่มาพร้อมกับ MSYS2 บน Windows ในกรณีของฉันทั้งซอร์สไฟล์และแพตช์มีการสิ้นสุดบรรทัด CRLF และการแปลงทั้งสองเป็น LF ไม่ทำงานเช่นกัน สิ่งที่ได้ผลคือ:

$ dos2unix patch-file.patch
$ patch -p1 < patch-file.patch
$ unix2dos modified-files...

patch จะแปลง line-endings เป็น LF ในทุกไฟล์ที่ได้รับการปะแก้ดังนั้นจึงจำเป็นต้องแปลงกลับเป็น CRLF

Obs: patchรุ่นที่ฉันใช้คือ 2.7.5


5

โดยปกติคุณสามารถแก้ไขได้โดยใช้-lตัวเลือก :

ใช้ตัวเลือก -l หรือ --ignore-whitespace ซึ่งทำให้แพทช์เปรียบเทียบอักขระว่าง (เช่นช่องว่างและแท็บ) อย่างอิสระเพื่อให้ลำดับช่องว่างที่ไม่ว่างใด ๆ ในไฟล์แพทช์ตรงกับลำดับช่องว่างที่ไม่ว่างในไฟล์อินพุต

นี่คือคุณสมบัติมาตรฐาน (ดูคำอธิบายการแก้ไขของ POSIX )

อย่างไรก็ตาม OP ได้แก้ไขคำถามเพื่อให้ความเห็นเกี่ยวกับวิธีการที่การสิ้นสุดของบรรทัดทำงานร่วมกับ git core.autocrlf ระหว่างระบบปฏิบัติการที่แตกต่างกันและเพิ่มตัวอย่างที่บ่งบอกว่าปัญหานั้นเกิดขึ้นกับไฟล์ใน Windows (ตรงกันข้ามกับตัวอย่างสไตล์ Unix) ในขณะที่patchพยายามรองรับความไม่ตรงกันระหว่าง CRLF และ LF line-endings มันมีอคติที่จะเข้าใจว่ามีการใช้หลัง หากไฟล์แพตช์มีจุดจบของ CRLF ในขณะที่ไฟล์ที่จะทำการแพตช์ไม่ได้ไฟล์นั้นจะทำการกู้คืนดังเช่นในบันทึกตัวอย่างนี้:

(Stripping trailing CRs from patch.)
patching file xterm.log.html
(Stripping trailing CRs from patch.)
patching file xterm.man
(Stripping trailing CRs from patch.)
patching file xtermcfg.hin

ในการตรวจสอบซอร์สโค้ดในsimilarฟังก์ชั่น GNU patchจะใช้ช่องว่างเป็นspaceและTabด้วยการจัดการพิเศษบางอย่างตามว่าเส้นนั้นมี LF ท้ายหรือไม่ CR ไม่ได้ถูกกล่าวถึง มันให้ความสนใจcheck_line_endingsแต่ใช้ข้อมูลนั้นเป็นส่วนหนึ่งของข้อความเท่านั้นเพื่อช่วยวินิจฉัยการปฏิเสธ มันแยก CRs ต่อท้ายในpget_lineยกเว้นว่ามีการกำหนด--binaryตัวเลือกไว้

โปรแกรมแก้ไขของ GNU ไม่มีตัวเลือกในการบอกให้แปลงโปรแกรมแก้ไขที่มีการลงท้ายด้วย LF เป็น CRLF เพื่อนำไปใช้กับไฟล์ที่ปลายสายเป็น CRLF หากต้องการใช้มันอย่างน่าเชื่อถือสำหรับกรณีนี้ตัวเลือกคือ

  • แปลงไฟล์ทั้งหมดเพื่อใช้ตอนจบ LF หรือ
  • แปลงไฟล์ทั้งหมดเพื่อใช้ตอนจบ CRLF และเพิ่ม--binaryตัวเลือก

5
--ignore-whitespace (ไม่มีเส้นประที่สอง) ไม่ได้ช่วยด้วยคำถามที่ฉันอัพเดท
user1709408

0

ฉันมีปัญหาที่คล้ายกันใน Cygwin ในกรณีของฉันการแก้ไขคือการใช้-iตั้งค่าสถานะแทนการอ่านจาก stdin

ต่อไปนี้ล้มเหลวโดยมีข้อผิดพลาดในการสิ้นสุดบรรทัดที่ต่างกัน

patch -t -N -r - -p0 < patchfile

แต่ต่อไปนี้ประสบความสำเร็จ:

patch -t -N -r - -p0 -i patchfile

ฉันไม่แน่ใจเกี่ยวกับสาเหตุ แต่ปล่อยไว้ที่นี่ในกรณีที่มีคนมีปัญหาเดียวกัน

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.