git thay thế LF bằng CRLF

Chạy git trên máy Windows XP, sử dụng bash. Tôi đã xuất dự án của mình từ SVN, và sau đó nhân bản một kho lưu trữ trần.

Sau đó tôi dán xuất vào thư mục kho lưu trữ trần và thực hiện:

git add -A

Sau đó tôi nhận được một danh sách các tin nhắn nói:

LF sẽ được thay thế bằng CRLF

Sự phân nhánh của chuyển đổi này là gì? Đây là một giải pháp .NET trong Visual Studio.

Các thông báo này là do giá trị mặc định không chính xác core.autocrlftrên Windows.

Khái niệm autocrlflà xử lý chuyển đổi kết thúc dòng một cách minh bạch. Và nó làm được!

Tin xấu : giá trị cần phải được cấu hình bằng tay.
Tin tốt : chỉ nên thực hiện MỘT lần cho mỗi lần cài đặt git (cũng có thể cài đặt dự án).

Làm thế nào autocrlfcác công trình :

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

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

Ở đây crlf= điểm đánh dấu cuối dòng kiểu win, lf= unix-style (và mac osx).

(tiền osx crkhông bị ảnh hưởng cho bất kỳ ba tùy chọn nào ở trên)

Khi nào cảnh báo này hiển thị (trong Windows)

    - autocrlf= truenếu bạn có kiểu unix lftrong một trong các tệp của mình (= RARELY),
    - autocrlf= inputnếu bạn có kiểu win crlftrong một trong các tệp của mình (= gần như LUÔN),
    - autocrlf= false- KHÔNG BAO GIỜ!

Cảnh báo này có ý nghĩa gì

Cảnh báo " LF sẽ được thay thế bằng CRLF " nói rằng bạn (có autocrlf= true) sẽ mất LF kiểu unix của bạn sau chu kỳ kiểm tra cam kết (nó sẽ được thay thế bằng CRLF theo kiểu cửa sổ). Git không mong đợi bạn sử dụng kiểu dáng unix dưới cửa sổ.

Cảnh báo " CRLF sẽ được thay thế bởi LF " nói rằng bạn (có autocrlf= input) sẽ mất CRLF theo kiểu cửa sổ của bạn sau một chu kỳ kiểm tra cam kết (nó sẽ được thay thế bằng kiểu unix kiểu unix). Đừng sử dụng inputdưới cửa sổ.

Một cách khác để cho thấy cách làm autocrlfviệc

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

trong đó x là CRLF (kiểu cửa sổ) hoặc LF (kiểu unix) và mũi tên là viết tắt của

file to commit -> repository -> checked out file

Làm thế nào để khắc phục

Giá trị mặc định cho core.autocrlfđược chọn trong quá trình cài đặt git và được lưu trữ trong gitconfig ( %ProgramFiles(x86)%\git\etc\gitconfig) trên toàn hệ thống . Ngoài ra còn có (xếp theo thứ tự sau):

   - gitconfig "toàn cầu" (mỗi người dùng) được đặt tại ~/.gitconfig, nhưng một gitconfig
   "toàn cầu" (trên mỗi người dùng) tại $XDG_CONFIG_HOME/git/confighoặc $HOME/.config/git/configvà
   - "cục bộ" (mỗi repo) gitconfig tại .git/configthư mục làm việc.

Vì vậy, hãy viết git config core.autocrlfvào thư mục làm việc để kiểm tra giá trị hiện đang sử dụng và

   - thêm autocrlf=falsevào giải pháp gitconfig # per-system trên toàn hệ thống
   - git config --global core.autocrlf false            # giải pháp cho mỗi người dùng
   - git config --local core.autocrlf false              # giải pháp cho mỗi dự án

Cảnh báo
- git configcài đặt có thể bị ghi đè bởi gitattributescài đặt.
- crlf -> lfchuyển đổi chỉ xảy ra khi thêm tệp mới, crlftệp đã tồn tại trong repo không bị ảnh hưởng.

Đạo đức (dành cho Windows):
    - use core.autocrlf= truenếu bạn dự định sử dụng dự án này trong Unix (và không muốn định cấu hình trình soạn thảo / IDE của bạn để sử dụng kết thúc dòng unix),
    - use core.autocrlf= falsenếu bạn dự định chỉ sử dụng dự án này trong Windows ( hoặc bạn đã định cấu hình trình soạn thảo / IDE của mình để sử dụng các kết thúc dòng unix),
    - không bao giờ sử dụng core.autocrlf= inputtrừ khi bạn có lý do chính đáng ( ví dụ: nếu bạn đang sử dụng các tiện ích unix dưới cửa sổ hoặc nếu bạn gặp phải các vấn đề về makefiles),

PS Chọn gì khi cài đặt git cho Windows?
Nếu bạn sẽ không sử dụng bất kỳ dự án nào trong Unix, đừng đồng ý với tùy chọn đầu tiên mặc định. Chọn cái thứ ba ( Thanh toán nguyên trạng, cam kết nguyên trạng ). Bạn sẽ không thấy tin nhắn này. Không bao giờ.

PPS Sở thích cá nhân của tôi là cấu hình trình soạn thảo / IDE để sử dụng các kết thúc kiểu Unix và cài đặt core.autocrlfthành false.

Git có ba chế độ xử lý kết thúc dòng:

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

Bạn có thể đặt chế độ để sử dụng bằng cách thêm một tham số bổ sung truehoặc falsevào dòng lệnh trên.

Nếu core.autocrlfđược đặt thành true, điều đó có nghĩa là bất cứ khi nào bạn thêm một tệp vào repo git mà git nghĩ là một tệp văn bản, nó sẽ biến tất cả các kết thúc dòng CRLF thành chỉ trước khi lưu nó vào cam kết. Bất cứ khi nào bạn có git checkoutmột cái gì đó, tất cả các tệp văn bản sẽ tự động được kết thúc dòng LF của chúng thành các kết thúc CRLF. Điều này cho phép phát triển một dự án trên các nền tảng sử dụng các kiểu kết thúc dòng khác nhau mà không cam kết rất ồn ào vì mỗi trình soạn thảo thay đổi kiểu kết thúc dòng vì kiểu kết thúc dòng luôn luôn là LF.

Tác dụng phụ của việc chuyển đổi thuận tiện này và đây là điều mà cảnh báo bạn đang gặp phải là, nếu một tệp văn bản mà bạn là tác giả ban đầu có kết thúc LF thay vì CRLF, nó sẽ được lưu trữ với LF như bình thường, nhưng khi được kiểm tra ra sau nó sẽ có kết thúc CRLF. Đối với các tệp văn bản bình thường, điều này thường là tốt. Cảnh báo là "thông tin của bạn" trong trường hợp này, nhưng trong trường hợp git đánh giá không chính xác tệp nhị phân là tệp văn bản, thì đó là một cảnh báo quan trọng vì git sau đó sẽ làm hỏng tệp nhị phân của bạn.

Nếu core.autocrlfđược đặt thành false, không có chuyển đổi kết thúc dòng nào được thực hiện, vì vậy các tệp văn bản được kiểm tra nguyên trạng. Điều này thường hoạt động tốt, miễn là tất cả các nhà phát triển của bạn đều ở trên Linux hoặc tất cả trên Windows. Nhưng theo kinh nghiệm của tôi, tôi vẫn có xu hướng nhận được các tệp văn bản với các kết thúc dòng hỗn hợp mà cuối cùng gây ra vấn đề.

Sở thích cá nhân của tôi là để cài đặt bật ON, với tư cách là nhà phát triển Windows.

Xem http://kernel.org/pub/software/scm/git/docs/git-config.html để biết thông tin cập nhật bao gồm giá trị "đầu vào".

Nếu bạn đã kiểm tra mã, các tệp đã được lập chỉ mục. Sau khi thay đổi cài đặt git của bạn, hãy nói bằng cách chạy:

git config --global core.autocrlf input 

bạn nên làm mới các chỉ mục với

git rm --cached -r . 

và viết lại chỉ số git với

git reset --hard

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

Lưu ý: điều này sẽ loại bỏ các thay đổi cục bộ của bạn, xem xét việc xóa chúng trước khi bạn làm điều này.

git config core.autocrlf false

Cả unix2dos và dos2unix đều có sẵn trong windows với gitbash. Bạn có thể sử dụng lệnh sau để thực hiện chuyển đổi UNIX (LF) -> DOS (CRLF). Do đó, bạn sẽ không nhận được cảnh báo.

unix2dos filename

hoặc là

dos2unix -D filename

Nhưng, đừng chạy lệnh này trên bất kỳ tệp CRLF hiện có nào, sau đó bạn sẽ nhận được các dòng mới trống mỗi dòng thứ hai.

dos2unix -D filenamesẽ không hoạt động với mọi hệ điều hành. Vui lòng kiểm tra liên kết này để tương thích.

Nếu vì lý do nào đó bạn cần buộc lệnh thì sử dụng --force. Nếu nó nói không hợp lệ thì sử dụng -f.

Tôi nghĩ rằng câu trả lời của @ Basiloungas đã gần nhưng đã lỗi thời (ít nhất là trên Mac).

Mở tệp ~ / .gitconfig và đặt safecrlfthành false

[core]
       autocrlf = input
       safecrlf = false

Điều đó * sẽ làm cho nó bỏ qua phần cuối của dòng char rõ ràng (dù sao cũng làm việc cho tôi).

Một bài viết của GitHub về kết thúc dòng thường được đề cập khi nói về chủ đề này.

Trải nghiệm cá nhân của tôi với việc sử dụng core.autocrlfcài đặt cấu hình thường được đề xuất là rất hỗn hợp.

Tôi đang sử dụng Windows với Cygwin, xử lý cả các dự án Windows và UNIX vào các thời điểm khác nhau. Ngay cả các dự án Windows của tôi đôi khi cũng sử dụng bashcác tập lệnh shell, yêu cầu kết thúc dòng UNIX (LF).

Sử dụng core.autocrlfcài đặt được đề xuất của GitHub cho Windows, nếu tôi kiểm tra một dự án UNIX (hoạt động hoàn hảo trên Cygwin - hoặc có thể tôi đang đóng góp cho dự án mà tôi sử dụng trên máy chủ Linux của mình), các tệp văn bản được kiểm tra bằng Windows (CRLF ) kết thúc dòng, tạo ra vấn đề.

Về cơ bản, đối với một môi trường hỗn hợp như tôi có, đặt toàn cầu core.autocrlfthành bất kỳ tùy chọn nào sẽ không hoạt động tốt trong một số trường hợp. Tùy chọn này có thể được đặt trên cấu hình git (kho lưu trữ) cục bộ, nhưng ngay cả điều đó sẽ không đủ tốt cho một dự án chứa cả nội dung liên quan đến Windows và UNIX (ví dụ: tôi có một dự án Windows với một số bashtập lệnh tiện ích).

Sự lựa chọn tốt nhất mà tôi đã tìm thấy là tạo các tệp .gitattribut trên mỗi kho lưu trữ . Các bài viết GitHub đề cập đến nó.
Ví dụ từ bài viết đó:

# 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

Trong một kho lưu trữ của dự án của tôi:

* 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

Có thêm một chút thứ để thiết lập, nhưng hãy thực hiện một lần cho mỗi dự án và bất kỳ người đóng góp nào trên bất kỳ HĐH nào cũng không gặp rắc rối với kết thúc dòng khi làm việc với dự án này.

Trong vim mở tệp (ví dụ :e YOURFILEENTER:), sau đó

:set noendofline binary
:wq

Tôi cũng có vấn đề này.

SVN không thực hiện bất kỳ chuyển đổi kết thúc dòng nào, vì vậy các tệp được cam kết với các kết thúc dòng CRLF còn nguyên vẹn. Nếu sau đó bạn sử dụng git-svn để đưa dự án vào git thì các kết thúc CRLF vẫn tồn tại trong kho git, đây không phải là trạng thái mà git mong muốn tìm thấy - mặc định chỉ có các kết thúc dòng unix / linux (LF) đi vào.

Sau đó, khi bạn kiểm tra các tệp trên windows, chuyển đổi autocrlf sẽ giữ nguyên các tệp (vì chúng đã có kết thúc chính xác cho nền tảng hiện tại), tuy nhiên quá trình quyết định xem có sự khác biệt nào với các tệp được kiểm tra thực hiện chuyển đổi ngược lại không trước khi so sánh, dẫn đến việc so sánh những gì nó nghĩ là một tệp trong tệp đã kiểm tra với một CRLF bất ngờ trong kho lưu trữ.

Theo như tôi có thể thấy sự lựa chọn của bạn là:

1. Nhập lại mã của bạn vào kho lưu trữ git mới mà không sử dụng git-svn, điều này có nghĩa là các kết thúc dòng được chuyển đổi trong cam kết git nội bộ --all
2. Đặt autocrlf thành false và bỏ qua thực tế là các kết thúc dòng không theo kiểu ưa thích của git
3. Kiểm tra các tệp của bạn với autocrlf tắt, sửa tất cả các kết thúc dòng, kiểm tra lại mọi thứ và bật lại.
4. Viết lại lịch sử kho lưu trữ của bạn để cam kết ban đầu không còn chứa CRLF mà git không mong đợi. (Thông báo trước về việc viết lại lịch sử được áp dụng)

Lưu ý: nếu bạn chọn tùy chọn # 2 thì kinh nghiệm của tôi là một số công cụ phụ trợ (rebase, patch, v.v.) không đối phó với các tệp CRLF và bạn sẽ sớm kết thúc với các tệp có kết hợp CRLF và LF (dòng không nhất quán kết thúc). Tôi biết không có cách nào để có được tốt nhất của cả hai.

Xóa phần bên dưới khỏi tệp ~ / .gitattribut

* text=auto

sẽ ngăn git kiểm tra kết thúc dòng ở vị trí đầu tiên.

Nó nên đọc:

cảnh báo: ( Nếu bạn kiểm tra nó / hoặc sao chép vào một thư mục khác với core.autocrlf hiện tại của bạntrue ,) LF sẽ được thay thế bằng CRLF

Các tập tin sẽ có kết thúc dòng ban đầu của nó trong thư mục làm việc ( hiện tại ) của bạn .

Bức ảnh này sẽ giải thích ý nghĩa của nó.

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

echo "* -crlf" > .gitattributes 

Thực hiện điều này trên một cam kết hoặc git riêng biệt vẫn có thể thấy toàn bộ tệp được sửa đổi khi bạn thực hiện một thay đổi duy nhất (tùy thuộc vào việc bạn đã thay đổi tùy chọn autocrlf)

Điều này thực sự làm việc. Git sẽ tôn trọng các kết thúc dòng trong các dự án kết thúc dòng hỗn hợp và không cảnh báo bạn về chúng.

Tôi không biết nhiều về git trên Windows, nhưng ...

Xuất hiện với tôi rằng git đang chuyển đổi định dạng trả về để phù hợp với định dạng của nền tảng đang chạy (Windows). CRLF là định dạng trả về mặc định trong Windows, trong khi đó, định dạng trả về mặc định cho hầu hết các hệ điều hành khác.

Rất có thể, định dạng trả về sẽ được điều chỉnh đúng khi mã được chuyển sang hệ thống khác. Tôi cũng cho rằng git đủ thông minh để giữ các tệp nhị phân nguyên vẹn thay vì cố gắng chuyển đổi các tệp LF thành CRLF, giả sử là JPEG.

Tóm lại, có lẽ bạn không cần phải băn khoăn quá nhiều về chuyển đổi này. Tuy nhiên, nếu bạn đi lưu trữ dự án của mình dưới dạng tarball, các lập trình viên đồng nghiệp có thể sẽ đánh giá cao việc có các đầu cuối dòng LF hơn là CRLF. Tùy thuộc vào mức độ bạn quan tâm (và tùy thuộc vào việc bạn không sử dụng Notepad), bạn có thể muốn đặt git để sử dụng trả về LF nếu bạn có thể :)

Phụ lục: CR là mã ASCII 13, LF là mã ASCII 10. Do đó, CRLF là hai byte, trong khi đó, LF là một.

Hãy chắc chắn rằng bạn đã cài đặt git mới nhất.
Tôi đã làm như trên git config core.autocrlf false, khi sử dụng git (phiên bản 2.7.1), nhưng nó không hoạt động.
Sau đó, nó hoạt động ngay khi nâng cấp git (từ 2.7.1 lên 2.20.1).

1. Mở tệp trong Notepad ++.
2. Chuyển đến Chỉnh sửa / Chuyển đổi EOL.
3. Nhấp vào Định dạng Windows.
4. Lưu các tập tin.

Câu hỏi của OP có liên quan đến windows và tôi không thể sử dụng những người khác mà không vào thư mục hoặc thậm chí chạy tệp trong Notepad ++ vì quản trị viên không hoạt động .. Vì vậy phải đi theo lộ trình này:

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

Nhiều trình soạn thảo văn bản cho phép bạn thay đổi thành LF, xem hướng dẫn của Atom bên dưới. Đơn giản và rõ ràng.

Bấm CRLFvào dưới cùng bên phải:

Chọn LFtrong danh sách thả xuống trên cùng:

Trong lời nhắc shell GNU / Linux, các lệnh dos2unix & unix2dos cho phép bạn dễ dàng chuyển đổi / định dạng các tệp của mình đến từ MS Windows

CRLF có thể gây ra một số vấn đề trong khi sử dụng "mã" của bạn trong hai hệ điều hành khác nhau (Linux và Windows). Kịch bản python của tôi đã được viết trong container docker Linux và sau đó được đẩy bằng Windows git-bash. Nó đã cho tôi cảnh báo rằng LF sẽ được thay thế bằng CRLF. Tôi đã không cho nó nhiều suy nghĩ nhưng sau đó khi tôi bắt đầu kịch bản sau đó, nó nói /usr/bin/env: 'python\r': No such file or directory. Bây giờ là một \rnhánh cho bạn. Windows sử dụng "CR" - trả về vận chuyển - trên đầu trang '\ n' làm ký tự dòng mới - \n\r. Đó là điều bạn có thể phải xem xét.

Hầu hết các công cụ trong Windows chỉ chấp nhận LF trong tệp văn bản. Ví dụ: bạn có thể kiểm soát hành vi cho Visual Studio trong một tệp có tên '.editorconfig' với nội dung ví dụ sau (phần):

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

Chỉ Windows-Notepad ban đầu không hoạt động với LF nhưng có một số công cụ chỉnh sửa đơn giản phù hợp hơn có sẵn!

Do đó, bạn cũng nên sử dụng LF trong các tệp văn bản trong Windows. Đây là thông điệp của tôi, đề nghị stronlgy! Không có lý do để sử dụng CRLF trong windows!

(Cuộc thảo luận tương tự đang sử dụng \ in bao gồm các đường dẫn trong C / ++, đó là nhảm nhí, sử dụng #include <pathTo / myheader.h> với dấu gạch chéo!

Do đó cài đặt thích hợp cho git là

git config core.autocrlf false

Thông điệp của tôi: Hãy quên những chương trình tư duy cũ như dos2unix và unix2dos. Làm rõ trong nhóm của bạn rằng LF phù hợp để sử dụng trong Windows.