Cách chuyển đổi kết thúc dòng hoạt động với git core.autocrlf giữa các hệ điều hành khác nhau

Tôi đã đọc rất nhiều câu hỏi và câu trả lời khác nhau trên Stack Overflow cũng như tài liệu git về cách cài đặt core.autocrlf hoạt động.

Đây là sự hiểu biết của tôi từ những gì tôi đã đọc:

Các máy khách Unix và Mac OSX (tiền OSX sử dụng CR) sử dụng các kết thúc dòng LF.
Máy khách Windows sử dụng kết thúc dòng CRLF.

Khi core.autocrlf được đặt thành true trên máy khách, kho git luôn lưu trữ các tệp ở định dạng kết thúc dòng LF và kết thúc dòng trong các tệp trên máy khách được chuyển đổi qua lại khi kiểm tra / cam kết cho các máy khách (ví dụ Windows) không sử dụng Kết thúc dòng -LF, bất kể định dạng nào các tệp kết thúc dòng trên máy khách (điều này không đồng ý với định nghĩa của Tim Clem - xem cập nhật bên dưới).

Dưới đây là một ma trận cố gắng ghi lại tài liệu giống nhau cho các cài đặt 'đầu vào' và 'sai' của core.autocrlf với các dấu hỏi mà tôi không chắc chắn về hành vi chuyển đổi kết thúc dòng.

Câu hỏi của tôi là:

1. Các dấu hỏi nên là gì?
2. Ma trận này có đúng với "dấu hỏi không" không?

Tôi sẽ cập nhật các dấu hỏi từ các câu trả lời khi sự đồng thuận dường như được hình thành.

                       giá trị core.autocrlf
            đúng đầu vào sai
-------------------------------------------------- --------
cam kết | đổi ? ?
mới | sang LF (chuyển đổi thành LF?) (không chuyển đổi?)

cam kết | chuyển đổi sang? Không
hiện có | Chuyển đổi (chuyển đổi sang LF?)

kiểm tra | chuyển đổi sang? Không
hiện có | Chuyển đổi CRLF (không chuyển đổi?)

Tôi không thực sự tìm kiếm ý kiến ​​về ưu và nhược điểm của các cài đặt khác nhau. Tôi chỉ tìm kiếm dữ liệu cho thấy rõ cách mong đợi git hoạt động với mỗi trong ba cài đặt.

-

Cập nhật 17/08/2012 : Sau khi đọc bài viết của Tim Clem được liên kết bởi JJD trong các bình luận, tôi đã sửa đổi một số giá trị trong các giá trị "không xác định" trong bảng trên, cũng như thay đổi "thanh toán hiện có | true để chuyển đổi sang CRLF thay vì chuyển đổi sang máy khách ". Dưới đây là những định nghĩa anh ta đưa ra, rõ ràng hơn bất cứ điều gì tôi thấy ở nơi khác:

core.autocrlf = sai

Đây là mặc định, nhưng hầu hết mọi người được khuyến khích thay đổi điều này ngay lập tức. Kết quả của việc sử dụng false là Git không bao giờ gây rối với các kết thúc dòng trên tệp của bạn. Bạn có thể kiểm tra các tệp bằng LF hoặc CRLF hoặc CR hoặc một số kết hợp ngẫu nhiên của ba và Git không quan tâm. Điều này có thể làm cho diffs khó đọc hơn và hợp nhất khó khăn hơn. Hầu hết mọi người làm việc trong thế giới Unix / Linux đều sử dụng giá trị này vì họ không gặp vấn đề về CRLF và họ không cần Git để làm thêm bất cứ khi nào tệp được ghi vào cơ sở dữ liệu đối tượng hoặc được ghi vào thư mục làm việc.

core.autocrlf = đúng

Điều này có nghĩa là Git sẽ xử lý tất cả các tệp văn bản và đảm bảo rằng CRLF được thay thế bằng LF khi ghi tệp đó vào cơ sở dữ liệu đối tượng và biến tất cả các LF trở lại thành CRLF khi ghi vào thư mục làm việc. Đây là cài đặt được đề xuất trên Windows vì nó đảm bảo rằng kho lưu trữ của bạn có thể được sử dụng trên các nền tảng khác trong khi vẫn giữ CRLF trong thư mục làm việc của bạn.

core.autocrlf = đầu vào

Điều này có nghĩa là Git sẽ xử lý tất cả các tệp văn bản và đảm bảo rằng CRLF được thay thế bằng LF khi ghi tệp đó vào cơ sở dữ liệu đối tượng. Nó sẽ không, tuy nhiên, làm ngược lại. Khi bạn đọc các tập tin ra khỏi cơ sở dữ liệu đối tượng và ghi chúng vào thư mục làm việc, chúng vẫn sẽ có các biểu thức để biểu thị cuối dòng. Cài đặt này thường được sử dụng trên Unix / Linux / OS X để ngăn CRLF không được ghi vào kho lưu trữ. Ý tưởng là nếu bạn dán mã từ trình duyệt web và vô tình có CRLF vào một trong các tệp của bạn, Git sẽ đảm bảo rằng chúng đã được thay thế bằng các tệp LF khi bạn viết vào cơ sở dữ liệu đối tượng.

Bài viết của Tim rất tuyệt vời, điều duy nhất tôi có thể nghĩ là còn thiếu là anh ta giả định rằng kho lưu trữ ở định dạng LF, điều này không nhất thiết đúng, đặc biệt là đối với các dự án chỉ dành cho Windows.

So sánh bài viết của Tim với câu trả lời được bình chọn cao nhất từ ​​trước đến nay của jmlane cho thấy sự đồng ý hoàn hảo về cài đặt đúng và đầu vào cũng như sự bất đồng về cài đặt sai.

Giải thích tốt nhất về cách thức core.autocrlfhoạt động được tìm thấy trên trang man gitattribut , trong phần textthuộc tính.

Đây là cách core.autocrlfhoạt động hiện tại (hoặc ít nhất là từ v1.7.2 từ những gì tôi biết):

• core.autocrlf = true
  1. Các tệp văn bản được kiểm tra từ kho lưu trữ chỉ có các LFký tự được chuẩn hóa CRLFtrong cây làm việc của bạn; các tệp có CRLFtrong kho sẽ không được chạm vào
  2. Tập tin văn bản mà chỉ có LFnhân vật trong kho, được chuẩn hóa từ CRLFđếnLF khi trở lại cam kết kho. Các tập tin có CRLFtrong kho lưu trữ sẽ được cam kết không bị ảnh hưởng.
• core.autocrlf = input
  1. Các tệp văn bản được kiểm xuất từ ​​kho lưu trữ sẽ giữ các ký tự EOL gốc trong cây làm việc của bạn.
  2. Các tệp văn bản trong cây làm việc của bạn với các CRLFký tự được chuẩn hóa thànhLF khi được cam kết trở lại kho lưu trữ.
• core.autocrlf = false
  1. core.eol ra lệnh các ký tự EOL trong tệp văn bản của cây làm việc của bạn.
  2. core.eol = nativetheo mặc định, điều đó có nghĩa là Windows EOL CRLFvà * nix EOL đang hoạt LFđộng.
  3. gitattributesCài đặt kho lưu trữ xác định chuẩn hóa ký tự EOL cho các cam kết với kho lưu trữ (mặc định là chuẩn hóa thành các LFký tự).

Tôi mới chỉ nghiên cứu vấn đề này gần đây và tôi cũng thấy tình hình rất phức tạp. Các core.eolthiết lập chắc chắn đã giúp làm sáng tỏ cách nhân vật EOL được xử lý bởi git.

Vấn đề EOL trong các dự án đa nền tảng đã khiến cuộc sống của tôi trở nên khốn khổ trong một thời gian dài. Các vấn đề thường phát sinh khi đã có các tệp có EOL khác nhau và hỗn hợp đã có trong repo. Điều này có nghĩa rằng:

1. Repo có thể có các tệp khác nhau với các EOL khác nhau
2. Một số tệp trong repo có thể có EOL hỗn hợp, ví dụ: kết hợp CRLFvà LFtrong cùng một tệp.

Làm thế nào điều này xảy ra không phải là vấn đề ở đây, nhưng nó xảy ra.

Tôi đã chạy một số thử nghiệm chuyển đổi trên Windows cho các chế độ khác nhau và sự kết hợp của chúng.
Đây là những gì tôi nhận được, trong một bảng sửa đổi một chút:

                 | Kết quả chuyển đổi khi | Kết quả chuyển đổi khi
                 | cam kết tập tin với nhiều | kiểm tra TỪ repo -
                 | EOL VÀO repo và | với các tập tin hỗn hợp trong đó và
                 | giá trị core.autocrlf: | giá trị core.autocrlf:           
-------------------------------------------------- ------------------------------
Tập tin | đúng | đầu vào | sai | đúng | đầu vào | sai
-------------------------------------------------- ------------------------------
Windows-CRLF | CRLF -> LF | CRLF -> LF | như là | như là | như là | như là
Unix -LF | như là | như là | như là | LF -> CRLF | như là | như là
Mac -CR | như là | như là | như là | như là | như là | như là
Hỗn hợp-CRLF + LF | như là | như là | như là | như là | như là | như là
Hỗn hợp-CRLF + LF + CR | như là | như là | như là | như là | như là | như là

Như bạn có thể thấy, có 2 trường hợp khi chuyển đổi xảy ra trên cam kết (3 cột bên trái). Trong các trường hợp còn lại, các tệp được cam kết nguyên trạng.

Khi thanh toán (3 cột bên phải), chỉ có 1 trường hợp chuyển đổi xảy ra khi:

1. core.autocrlflà true và
2. tập tin trong repo có LFEOL.

Đáng ngạc nhiên nhất đối với tôi, và tôi nghi ngờ, nguyên nhân của nhiều vấn đề EOL là do không có cấu hình trong đó EOL hỗn hợp như CRLF+ LFđược chuẩn hóa.

Cũng lưu ý rằng Mac EOL "cũ" CRchỉ không bao giờ được chuyển đổi.
Điều này có nghĩa là nếu tập lệnh chuyển đổi EOL được viết xấu cố gắng chuyển đổi tệp kết thúc hỗn hợp với CRLFs + LFs, chỉ bằng cách chuyển đổi LFs thành CRLFs, thì nó sẽ để tệp ở chế độ hỗn hợp với "cô đơn" CRbất cứ nơi nào CRLFđược chuyển đổi thành CRCRLF.
Git sau đó sẽ không chuyển đổi bất cứ thứ gì, ngay cả trong truechế độ, và sự tàn phá EOL vẫn tiếp tục. Điều này thực sự đã xảy ra với tôi và làm hỏng các tệp của tôi rất tệ, vì một số trình soạn thảo và trình biên dịch (ví dụ VS2010) không thích Mac EOLs.

Tôi đoán cách duy nhất để thực sự xử lý các vấn đề này là thỉnh thoảng bình thường hóa toàn bộ repo bằng cách kiểm tra tất cả các tệp trong inputhoặc falsechế độ, chạy chuẩn hóa đúng và cam kết lại các tệp đã thay đổi (nếu có). Trên Windows, có lẽ tiếp tục làm việc với core.autocrlf true.

Mọi thứ sắp thay đổi trên mặt trận "chuyển đổi eol", với Git 1.7.2 sắp tới :

Một cài đặt cấu hình mới core.eolđang được thêm / phát triển :

Đây là sự thay thế cho core.eolcam kết 'Thêm " " cấu hình hiện có pu(biến cuối cùng trong chuỗi của tôi).
Thay vì ngụ ý rằng " core.autocrlf=true" là sự thay thế cho " * text=auto", nó cho thấy rõ thực tế autocrlflà chỉ dành cho người dùng muốn làm việc với CRLF trong thư mục làm việc của họ trên kho lưu trữ không có chuẩn hóa tệp văn bản .
Khi được bật, "core.eol" sẽ bị bỏ qua.

Giới thiệu một biến cấu hình mới, " core.eol", cho phép người dùng đặt kết thúc dòng nào sẽ sử dụng cho các tệp chuẩn hóa cuối dòng trong thư mục làm việc.
Nó mặc định là " native", có nghĩa là CRLF trên Windows và LF ở mọi nơi khác. Lưu ý rằng " core.autocrlf" ghi đè core.eol.
Điều này có nghĩa rằng:

[core]
  autocrlf = true

đặt CRLF trong thư mục làm việc ngay cả khi core.eolđược đặt thành " lf".

core.eol:

Đặt loại kết thúc dòng sẽ sử dụng trong thư mục làm việc cho các tệp có thuộc texttính được đặt.
Các lựa chọn thay thế là 'lf', 'crlf' và 'bản địa', sử dụng kết thúc dòng gốc của nền tảng.
Giá trị mặc định là native.

Các diễn biến khác đang được xem xét :

Đối với phiên bản 1.8, tôi sẽ cân nhắc việc core.autocrlfchỉ bật chế độ chuẩn hóa và để lại quyết định kết thúc dòng thư mục làm việc cho core.eol, nhưng điều đó sẽ phá vỡ các thiết lập của mọi người.

git 2.8 (tháng 3 năm 2016) cải thiện cách core.autocrlfảnh hưởng đến eol:

Xem cam kết 817a0c7 (23 tháng 2 năm 2016), cam kết 6e336a5 , cam kết df747b8 , cam kết df747b8 (10 tháng 2 năm 2016), cam kết df747b8 , cam kết df747b8 (10 tháng 2 năm 2016), và cam kết 4b4024f , cam kết bb211b4 , cam kết 92cce13 , cam kết 320d39c , cam kết 4b4024f , cam kết bb211b4 , cam kết 92cce13 , cam kết 320d39c (ngày 5 tháng 2 năm 2016) bởi Torsten Bögershausen ( tboegi) .
^{(Được hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết c6b94eb, Ngày 26 tháng 2 năm 2016)}

convert.c: cấu trúc lại crlf_action

Tái cấu trúc xác định và sử dụng crlf_action.
Ngày nay, khi không có crlfthuộc tính "" nào được đặt trên một tệp, crlf_actionđược đặt thành CRLF_GUESS. Sử dụng CRLF_UNDEFINEDthay thế và tìm kiếm " text" hoặc " eol" như trước đây.

Thay thế CRLF_GUESScách sử dụng cũ :

CRLF_GUESS && core.autocrlf=true -> CRLF_AUTO_CRLF
CRLF_GUESS && core.autocrlf=false -> CRLF_BINARY
CRLF_GUESS && core.autocrlf=input -> CRLF_AUTO_INPUT

Làm rõ hơn, những gì là, bằng cách xác định:

- CRLF_UNDEFINED : No attributes set. Temparally used, until core.autocrlf
                   and core.eol is evaluated and one of CRLF_BINARY,
                   CRLF_AUTO_INPUT or CRLF_AUTO_CRLF is selected
- CRLF_BINARY    : No processing of line endings.
- CRLF_TEXT      : attribute "text" is set, line endings are processed.
- CRLF_TEXT_INPUT: attribute "input" or "eol=lf" is set. This implies text.
- CRLF_TEXT_CRLF : attribute "eol=crlf" is set. This implies text.
- CRLF_AUTO      : attribute "auto" is set.
- CRLF_AUTO_INPUT: core.autocrlf=input (no attributes)
- CRLF_AUTO_CRLF : core.autocrlf=true  (no attributes)

Như torek thêm vào trong các ý kiến :

tất cả các bản dịch này (mọi chuyển đổi EOL từ eol=hoặc autocrlfcài đặt và cleanbộ lọc "") đều được chạy khi các tệp chuyển từ cây công việc sang chỉ mục , tức là trong thời gian git addchứ không phải tại git committhời điểm.
(Lưu ý rằng git commit -ahoặc --onlyhoặc --includelàm file add vào chỉ số tại thời điểm đó, mặc dù.)

Để biết thêm về điều đó, hãy xem "Sự khác biệt giữa autocrlf và eol " là gì.

core.autocrlfgiá trị không phụ thuộc vào loại HĐH mà trên giá trị mặc định của Windows là truevà đối với Linux - input. Tôi đã khám phá 3 giá trị có thể cho các trường hợp cam kết và thanh toán và đây là bảng kết quả:

╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ core.autocrlf ║     false    ║     input    ║     true     ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║               ║ LF   => LF   ║ LF   => LF   ║ LF   => LF   ║
║ git commit    ║ CR   => CR   ║ CR   => CR   ║ CR   => CR   ║
║               ║ CRLF => CRLF ║ CRLF => LF   ║ CRLF => LF   ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║               ║ LF   => LF   ║ LF   => LF   ║ LF   => CRLF ║
║ git checkout  ║ CR   => CR   ║ CR   => CR   ║ CR   => CR   ║
║               ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝

Đây là sự hiểu biết của tôi về nó cho đến nay, trong trường hợp nó giúp được ai đó.

core.autocrlf=true và core.safecrlf = true

Bạn có một kho lưu trữ trong đó tất cả các kết thúc dòng giống nhau , nhưng bạn làm việc trên các nền tảng khác nhau. Git sẽ đảm bảo các kết thúc dòng của bạn được chuyển đổi thành mặc định cho nền tảng của bạn. Vì sao vấn đề này? Giả sử bạn tạo một tệp mới. Trình soạn thảo văn bản trên nền tảng của bạn sẽ sử dụng các kết thúc dòng mặc định của nó. Khi bạn kiểm tra nó, nếu bạn không đặt core.autocrlf thành true, bạn đã đưa ra một dòng kết thúc không nhất quán cho ai đó trên nền tảng mặc định cho một dòng kết thúc khác. Tôi luôn đặt safecrlf vì tôi muốn biết rằng thao tác crlf có thể đảo ngược. Với hai cài đặt này, git đang sửa đổi các tệp của bạn, nhưng nó xác minh rằng các sửa đổi có thể đảo ngược .

core.autocrlf=false

Bạn có một kho lưu trữ đã có các kết thúc dòng hỗn hợp được kiểm tra và sửa các kết thúc dòng không chính xác có thể phá vỡ các thứ khác. Tốt nhất không nên nói với git để chuyển đổi kết thúc dòng trong trường hợp này, bởi vì sau đó nó sẽ làm trầm trọng thêm vấn đề mà nó được thiết kế để giải quyết - làm cho khác biệt dễ đọc hơn và hợp nhất ít đau hơn. Với cài đặt này, git không sửa đổi các tệp của bạn .

core.autocrlf=input

Tôi không sử dụng điều này bởi vì lý do cho việc này là để bao gồm một trường hợp sử dụng khi bạn đã tạo một tệp có kết thúc dòng CRLF trên nền tảng mặc định cho các kết thúc dòng LF. Thay vào đó, tôi thích làm cho trình soạn thảo văn bản của mình luôn lưu các tệp mới với mặc định kết thúc dòng của nền tảng.

Không, câu trả lời @jmlane là sai.

Dành cho Checkin (git add, git commit):

1. nếu thuộc texttính là Set, Set value to 'auto', chuyển đổi xảy ra enen tệp đã được cam kết với 'CRLF'
2. nếu texttài sản là Unset: không có gì xảy ra, enen choCheckout
3. nếu texttài sản là Unspecified, chuyển đổi phụ thuộc vàocore.autocrlf
   1. nếu autocrlf = input or autocrlf = true, chuyển đổi chỉ xảy ra khi tệp trong kho lưu trữ là 'LF', nếu nó là 'CRLF', sẽ không có gì xảy ra.
   2. nếu autocrlf = false, không có gì xảy ra

Dành cho Checkout:

1. nếu texttài sản là Unset: không có gì xảy ra.
2. nếu texttài sản là Set, Set value to 'auto: nó phụ thuộc vào core.autocrlf, core.eol.
   1. core.autocrlf = input: không có gì xảy ra
   2. core.autocrlf = true: việc chuyển đổi chỉ xảy ra khi tệp trong kho lưu trữ là 'LF', 'LF' -> 'CRLF'
   3. core.autocrlf = false: việc chuyển đổi chỉ xảy ra khi tệp trong kho lưu trữ là 'LF', 'LF' -> core.eol
3. nếu texttài sản làUnspecified , nó phụ thuộc vào core.autocrlf.
   1. giống như 2.1
   2. giống như 2.2
   3. Không, không có gì xảy ra, core.eol không hiệu quả khi texttài sản làUnspecified

Hành vi mặc định

Vì vậy, hành vi mặc định là texttài sản là Unspecifiedvà core.autocrlf = false:

1. để kiểm tra, không có gì xảy ra
2. để kiểm tra, không có gì xảy ra

Kết luận

1. nếu text tính được đặt, hành vi đăng ký phụ thuộc vào chính nó, không phụ thuộc vào autocrlf
2. autocrlf hoặc core.eol dành cho hành vi thanh toán và autocrlf> core.eol

Đã làm một số thử nghiệm cả trên linux và windows. Tôi sử dụng một tệp kiểm tra có chứa các dòng kết thúc bằng LF và cả các dòng kết thúc bằng CRLF.
Tập tin được cam kết, loại bỏ và sau đó kiểm tra. Giá trị của core.autocrlf được đặt trước cam kết và cả trước khi thanh toán. Kết quả là dưới đây.

commit core.autocrlf false, remove, checkout core.autocrlf false: LF=>LF   CRLF=>CRLF  
commit core.autocrlf false, remove, checkout core.autocrlf input: LF=>LF   CRLF=>CRLF  
commit core.autocrlf false, remove, checkout core.autocrlf true : LF=>LF   CRLF=>CRLF  
commit core.autocrlf input, remove, checkout core.autocrlf false: LF=>LF   CRLF=>LF  
commit core.autocrlf input, remove, checkout core.autocrlf input: LF=>LF   CRLF=>LF  
commit core.autocrlf input, remove, checkout core.autocrlf true : LF=>CRLF CRLF=>CRLF  
commit core.autocrlf true, remove, checkout core.autocrlf false: LF=>LF   CRLF=>LF  
commit core.autocrlf true, remove, checkout core.autocrlf input: LF=>LF   CRLF=>LF  
commit core.autocrlf true,  remove, checkout core.autocrlf true : LF=>CRLF CRLF=>CRLF