Git core.safecrlf hành vi khác nhau trên các tệp có cùng dòng cuối

Question

Tôi có máy Windows có dự án VS và tôi sử dụng cả Visual Studio và các công cụ từ môi trường Cygwin bao gồm Git. Đôi khi tôi nhận được kết thúc dòng khác nhau trong các tệp sau khi chỉnh sửa. Tôi muốn giải pháp đơn giản để kiểm tra tính nhất quán của dòng kết thúc trước khi họ đi đến repo. Git của core.safecrlf là điều đúng tôi cho là. Bây giờ tôi có một hành vi kỳ lạ:

tập tin A và B với các thông số sau:

$file A 
A: HTML document, UTF-8 Unicode text, with CRLF line terminators 
$file B 
B: HTML document, UTF-8 Unicode (with BOM) text, with CRLF line terminators 

file A là đã có trong repo, file B là cái mới. Lưu ý, cả hai đều có kết thúc dòng CRLF. Bây giờ, hãy thử giai đoạn chúng, core.safecrlf là true.

$git add A # ok 
$git add B # fails 
fatal: CRLF would be replaced by LF in B. 

Đang sử dụng core.safecrlf chính xác? Hoặc có lẽ tôi cần phải viết móc để kiểm tra các tập tin?

Ghi chú:

• thử với mã hóa tập tin khác nhau (có và không có BOM), không có sự khác biệt.
• có có liên quan core.autocrlf tính năng trong Git, thêm nó vào thẻ (Stackoverflow không có thẻ cho core.safecrlf)
• git phiên bản 1.8.5.rc1.17.g0ecd94d (tổng hợp từ các nguồn dưới Cygwin)

EDIT # 1: đã kiểm tra core.autocrlf - đó là input. Đã thay đổi thành false, bây giờ tôi có thể thêm cả hai tệp. Tại sao?

Answer 1

Theo chỉnh sửa sau, core.autocrlf = input là cài đặt gốc. Với cài đặt này, CRLF được chuyển thành LF khi được đăng ký vào kho và được giữ như vậy khi được kiểm tra. Điều này có nghĩa là một trình soạn thảo hiểu biết không kết thúc dòng Unix như Notepad sẽ làm rối loạn sự xuất hiện của phiên bản đã kiểm tra của tệp. Nó sẽ là một đường dài khổng lồ.

FWIW core.autocrlf = input là cài đặt ưu tiên trên hệ thống Unix và sử dụng công cụ xây dựng mặc định cygwin có thể được đặt theo cách đó. Trong Windows các thiết lập được đề nghị là core.autocrlf = true đó là những gì msysgit khuyến

core.safecrlf = true hủy bỏ việc chuyển đổi một tập tin nếu kiểm tra ra các tập tin sẽ dẫn đến một tập tin đã thay đổi và có thể bị hư hỏng đó sẽ là trường hợp nếu Notepad là trình soạn thảo. Đây là lý do tại sao tệp B bị hủy bỏ bởi vì nó sẽ bị sai lầm trong một trình soạn thảo như Notepad. Sự khác biệt giữa core.SAFEcrlf và core.AUTOcrlf cần được lưu ý.Đây là một trong các vấn đề về eyes glazing over khi hiểu được các kết thúc dòng

core.autocrlf = false là chế độ không quan tâm. Nó sẽ kiểm tra và kiểm tra các tập tin chính xác như họ đang có, đó là lý do tại sao các cam kết bây giờ làm việc. Điều này không phải là rất thông minh và không được khuyến khích vì nó gây ra vấn đề nếu các tập tin được chỉnh sửa trên cả Windows và hệ thống Unix và cũng nếu người dùng khác core.autocrlf cài đặt khác nhau và thay đổi kết thúc tệp.

sở thích riêng của tôi là để thiết lập core.autocrlf-input trên Windows nếu tất cả Windows biên tập viên và các công cụ xử lý file văn bản khác về dự án là dòng Unix kết thúc nhận thức được, nếu không đặt nó vào core.autocrlf = true cho Windows và core.autocrlf = input cho Unix. Trong mọi trường hợp, cách tiếp cận này bị lỗi thời bởi phương thức cấp trên của tệp .gitattributes.

Phương thức tệp .gitattributes xử lý tệp dựa trên tên tệp và được duy trì trong tất cả môi trường người dùng khi được kiểm tra vào thư mục hoạt động như .gitignore. Các cài đặt cho bao nhiêu tên tệp và loại có liên quan đến dự án của bạn sẽ được thêm vào .gitattributes. Cấu hình của bạn sau đó sẽ quay trở lại các cài đặt core.autocrlf và core.safecrlf cục bộ nếu tên tệp không khớp trong .gitattributes. Thêm * text=auto ở đầu .gitattributes sẽ gây ra git để thực hiện dự đoán tốt nhất về tên tệp không khớp với cài đặt .gitattributes sau này.

Trang web này, Mind the End of Your Line đã giúp tôi hiểu vấn đề tốt hơn. Bạn có thể đọc để biết thêm thông tin cơ bản về vấn đề này.

Answer 2

Lựa chọn kết thúc dòng CR LF không dễ hiểu. Có hai vị trí cho các mô tả ở chỗ nó được trình bày trong các tài liệu Git-attributes và Git-config.

Ban đầu có cài đặt autocrlf và sau đó có các phiên bản mới hơn có một số tính không tương thích tiềm ẩn (tức là thực hiện những điều không mong muốn như bạn chỉ ra).

Tôi có xu hướng đặt eol = LF, điều này làm cho tất cả các tệp văn bản được cam kết là kết thúc dòng LF (bạn có thể đặt thuộc tính là tệp nào được coi là văn bản) và sau đó thêm safecrlf để thực hiện kiểm tra chuyến đi khứ hồi.