git mengganti LF dengan CRLF

Menjalankan git pada mesin Windows XP, menggunakan bash. Saya mengekspor proyek saya dari SVN, dan kemudian mengkloning repositori kosong.

Saya kemudian menempelkan ekspor ke direktori repositori kosong, dan melakukan:

git add -A

Saya kemudian mendapat daftar pesan yang mengatakan:

LF akan digantikan oleh CRLF

Apa konsekuensi dari pertobatan ini? Ini adalah solusi .NET di Visual Studio.

Pesan-pesan ini disebabkan oleh nilai default yang salah core.autocrlfpada Windows.

Konsepnya autocrlfadalah untuk menangani konversi akhir baris secara transparan. Dan itu benar!

Berita buruk : nilai harus dikonfigurasi secara manual.
Berita bagus : itu hanya boleh dilakukan SATU kali per instalasi git (per pengaturan proyek juga mungkin).

Bagaimana cara autocrlfkerjanya :

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

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

Di sini crlf= penanda end-of-line win-style, lf= unix-style (dan mac osx).

(pre-osx crin tidak terpengaruh untuk salah satu dari tiga opsi di atas)

Kapan peringatan ini muncul (di bawah Windows)

    - autocrlf= truejika Anda memiliki gaya unix lfdi salah satu file Anda (= Jarang),
    - autocrlf= inputjika Anda memiliki gaya menang crlfdi salah satu file Anda (= hampir SELALU),
    - autocrlf= false- TIDAK PERNAH!

Apa artinya peringatan ini

Peringatan " LF akan digantikan oleh CRLF " mengatakan bahwa Anda (memiliki autocrlf= true) akan kehilangan LF gaya unix Anda setelah siklus commit-checkout (ini akan digantikan oleh CRLF gaya windows). Git tidak mengharapkan Anda untuk menggunakan LF unix-style di bawah windows.

Peringatan " CRLF akan digantikan oleh LF " mengatakan bahwa Anda (memiliki autocrlf= input) akan kehilangan CRLF gaya-windows setelah siklus komit-checkout (akan diganti dengan LF unix-style). Jangan gunakan di inputbawah windows.

Namun cara lain untuk menunjukkan cara autocrlfkerjanya

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

di mana x adalah CRLF (gaya windows) atau LF (gaya unix) dan panah mewakili

file to commit -> repository -> checked out file

Bagaimana cara memperbaiki

Nilai default untuk core.autocrlfdipilih selama instalasi git dan disimpan dalam gitconfig ( %ProgramFiles(x86)%\git\etc\gitconfig) seluruh sistem ( ). Juga ada (mengalir dalam urutan berikut):

   - gitconfig "global" (per-pengguna) terletak di ~/.gitconfig, gitconfig
   "global" (per-pengguna) lain di $XDG_CONFIG_HOME/git/configatau $HOME/.config/git/configdan
   - " gitconfig " lokal "(per-repo) di .git/configdalam direktori kerja.

Jadi, tulis git config core.autocrlfdi dir yang berfungsi untuk memeriksa nilai yang saat ini digunakan dan

   - tambahkan autocrlf=falseke solusi gitconfig # per-sistem di seluruh sistem
   - git config --global core.autocrlf false            # solusi per pengguna
   - git config --local core.autocrlf false              # solusi per proyek

Peringatan
- git configpengaturan dapat ditimpa oleh gitattributespengaturan.
- crlf -> lfKonversi hanya terjadi ketika menambahkan file baru, crlffile yang sudah ada di repo tidak terpengaruh.

Moral (untuk Windows):
    - use core.autocrlf= truejika Anda berencana untuk menggunakan proyek ini di bawah Unix juga (dan tidak mau mengkonfigurasi editor / IDE Anda untuk menggunakan ujung garis unix),
    - use core.autocrlf= falsejika Anda berencana untuk menggunakan proyek ini di bawah Windows saja ( atau Anda telah mengkonfigurasi editor / IDE Anda untuk menggunakan akhiran baris unix),
    - tidak pernah menggunakan core.autocrlf= inputkecuali Anda memiliki alasan yang baik untuk ( misalnya jika Anda menggunakan utilitas unix di bawah windows atau jika Anda mengalami masalah makefiles),

PS Apa yang harus dipilih ketika menginstal git untuk Windows?
Jika Anda tidak akan menggunakan salah satu proyek Anda di bawah Unix, jangan setuju dengan opsi pertama default. Pilih yang ketiga ( Periksa apa adanya, komit apa adanya ). Anda tidak akan melihat pesan ini. Pernah.

PPS Preferensi pribadi saya adalah mengonfigurasi editor / IDE untuk menggunakan ujung Unix-style, dan pengaturan core.autocrlfke false.

Git memiliki tiga mode bagaimana memperlakukan ujung baris:

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

Anda dapat mengatur mode untuk digunakan dengan menambahkan parameter tambahan trueatau falseke baris perintah di atas.

Jika core.autocrlfdisetel ke true, itu berarti bahwa setiap kali Anda menambahkan file ke repo git yang menurut git adalah file teks, itu akan mengubah semua akhiran garis CRLF menjadi hanya LF sebelum disimpan dalam komit. Setiap kali Anda melakukan git checkoutsesuatu, semua file teks secara otomatis akan memiliki ujung LF mereka dikonversi ke ujung CRLF. Hal ini memungkinkan pengembangan proyek lintas platform yang menggunakan gaya akhir baris yang berbeda tanpa komit menjadi sangat bising karena setiap editor mengubah gaya akhir baris karena gaya akhir baris selalu konsisten LF.

Efek samping dari konversi yang mudah digunakan ini, dan ini adalah tentang peringatan yang Anda lihat, adalah bahwa jika file teks yang Anda tulis awalnya memiliki akhiran LF bukan CRLF, itu akan disimpan dengan LF seperti biasa, tetapi ketika diperiksa keluar nanti akan memiliki akhiran CRLF. Untuk file teks normal ini biasanya baik-baik saja. Peringatan adalah "untuk informasi Anda" dalam kasus ini, tetapi dalam kasus git salah menilai file biner menjadi file teks, itu adalah peringatan penting karena git kemudian akan merusak file biner Anda.

Jika core.autocrlfdisetel ke false, tidak ada konversi akhir baris yang pernah dilakukan, jadi file teks diperiksa apa adanya. Ini biasanya berfungsi dengan baik, selama semua pengembang Anda berada di Linux atau semua di Windows. Namun dalam pengalaman saya, saya masih cenderung mendapatkan file teks dengan ujung garis campuran yang akhirnya menyebabkan masalah.

Preferensi pribadi saya adalah membiarkan pengaturannya AKTIF, sebagai pengembang Windows.

Lihat http://kernel.org/pub/software/scm/git/docs/git-config.html untuk info terbaru yang menyertakan nilai "input".

Jika Anda sudah memeriksa kode, file sudah diindeks. Setelah mengubah pengaturan git Anda, ucapkan dengan menjalankan:

git config --global core.autocrlf input 

Anda harus menyegarkan indeks dengan

git rm --cached -r . 

dan tulis ulang indeks git dengan

git reset --hard

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

Catatan: ini akan menghapus perubahan lokal Anda, pertimbangkan menyimpannya sebelum Anda melakukan ini.

git config core.autocrlf false

Baik unix2dos dan dos2unix tersedia di windows dengan gitbash. Anda dapat menggunakan perintah berikut untuk melakukan konversi UNIX (LF) -> DOS (CRLF). Karenanya, Anda tidak akan mendapatkan peringatan.

unix2dos filename

atau

dos2unix -D filename

Tapi, jangan jalankan perintah ini pada file CRLF yang ada, maka Anda akan mendapatkan baris kosong setiap baris kedua.

dos2unix -D filenametidak akan bekerja dengan setiap sistem operasi. Silakan periksa tautan ini untuk kompatibilitas.

Jika karena alasan tertentu Anda perlu memaksa perintah kemudian gunakan --force. Jika dikatakan tidak valid maka gunakan -f.

Saya pikir jawaban @ Basiloungas dekat tapi ketinggalan zaman (setidaknya pada Mac).

Buka file ~ / .gitconfig dan atur safecrlfke false

[core]
       autocrlf = input
       safecrlf = false

Itu * akan membuatnya mengabaikan end of line char rupanya (tetap bekerja untuk saya).

Artikel GitHub tentang akhir baris umumnya disebutkan ketika berbicara tentang topik ini.

Pengalaman pribadi saya dengan menggunakan core.autocrlfpengaturan konfigurasi yang sering disarankan sangat beragam.

Saya menggunakan Windows dengan Cygwin, berurusan dengan proyek Windows dan UNIX pada waktu yang berbeda. Bahkan proyek Windows saya terkadang menggunakan bashskrip shell, yang membutuhkan akhiran baris UNIX (LF).

Menggunakan core.autocrlfpengaturan yang disarankan GitHub untuk Windows, jika saya memeriksa proyek UNIX (yang bekerja dengan baik di Cygwin - atau mungkin saya berkontribusi pada proyek yang saya gunakan di server Linux saya), file teks diperiksa dengan Windows (CRLF ) akhiran baris, menciptakan masalah.

Pada dasarnya, untuk lingkungan campuran seperti yang saya miliki, menetapkan global core.autocrlfke salah satu opsi tidak akan berfungsi dengan baik dalam beberapa kasus. Opsi ini mungkin diatur pada konfigurasi git lokal (repositori), tetapi bahkan itu tidak akan cukup baik untuk proyek yang berisi hal-hal yang berhubungan dengan Windows dan UNIX (misalnya saya memiliki proyek Windows dengan beberapa bashskrip utilitas).

Pilihan terbaik yang saya temukan adalah membuat file .gitattributes per-repositori . The Artikel GitHub menyebutkan itu.
Contoh dari artikel itu:

# 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

Di salah satu repositori proyek saya:

* 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

Ini sedikit lebih banyak hal untuk diatur, tetapi lakukan sekali per proyek, dan setiap kontributor pada OS apa pun seharusnya tidak memiliki masalah dengan akhir baris ketika bekerja dengan proyek ini.

Dalam vim buka file (misalnya:) :e YOURFILEENTER, lalu

:set noendofline binary
:wq

Saya punya masalah ini juga.

SVN tidak melakukan konversi akhir baris, jadi file-file dikomit dengan akhiran CRLF utuh. Jika Anda kemudian menggunakan git-svn untuk meletakkan proyek ke git maka ujung CRLF tetap ada di dalam repositori git, yang bukan keadaan yang diharapkan git untuk menemukan dirinya sendiri - defaultnya adalah hanya memiliki akhiran baris unix / linux (LF) check in.

Ketika Anda kemudian memeriksa file di windows, konversi autocrlf membiarkan file tetap utuh (karena mereka sudah memiliki ujung yang benar untuk platform saat ini), namun proses yang memutuskan apakah ada perbedaan dengan file yang diperiksa melakukan konversi terbalik sebelum membandingkan, menghasilkan membandingkan apa yang dianggapnya adalah LF dalam file yang diperiksa dengan CRLF yang tidak terduga dalam repositori.

Sejauh yang saya lihat pilihan Anda adalah:

1. Impor ulang kode Anda ke repositori git baru tanpa menggunakan git-svn, ini berarti akhiran baris akan dikonversi dalam komit git awal --semua
2. Atur autocrlf menjadi false, dan abaikan fakta bahwa akhiran garis tidak sesuai dengan gaya git
3. Periksa file Anda dengan nonaktif, perbaiki semua akhir baris, periksa semuanya kembali, dan hidupkan kembali.
4. Tulis ulang riwayat repositori Anda sehingga komit asli tidak lagi berisi CRLF yang tidak diharapkan git. (Peringatan biasa tentang penulisan ulang sejarah berlaku)

Catatan Kaki: jika Anda memilih opsi # 2 maka pengalaman saya adalah bahwa beberapa alat pendukung (rebase, patch dll) tidak mengatasi file CRLF dan Anda akan cepat atau lambat menghasilkan file dengan campuran CRLF dan LF (garis tidak konsisten) akhir). Saya tahu tidak ada cara untuk mendapatkan yang terbaik dari keduanya.

Menghapus yang di bawah ini dari file ~ / .gitattributes

* text=auto

akan mencegah git dari memeriksa akhir baris di tempat pertama.

Itu harus membaca:

peringatan: ( Jika Anda memeriksanya / atau mengkloning ke folder lain dengan core.autocrlf Anda saat initrue ,) LF akan digantikan oleh CRLF

File akan memiliki akhiran garis aslinya di direktori kerja Anda ( saat ini ).

Gambar ini harus menjelaskan apa artinya.

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

echo "* -crlf" > .gitattributes 

Lakukan ini pada komit terpisah atau git mungkin masih melihat seluruh file telah dimodifikasi ketika Anda membuat perubahan tunggal (tergantung pada apakah Anda telah mengubah opsi autocrlf)

Ini benar-benar berfungsi. Git akan menghormati akhir baris dalam proyek akhir baris campuran dan tidak memperingatkan Anda tentang mereka.

Saya tidak tahu banyak tentang git di Windows, tapi ...

Muncul kepada saya bahwa git mengonversi format kembali agar sesuai dengan platform yang sedang berjalan (Windows). CRLF adalah format pengembalian default di Windows, sedangkan LF adalah format pengembalian default untuk sebagian besar OS lainnya.

Kemungkinannya, format pengembalian akan disesuaikan dengan benar ketika kode dipindahkan ke sistem lain. Saya juga berpendapat git cukup pintar untuk menjaga file biner tetap utuh daripada mencoba mengkonversi LF ke CRLF, katakanlah, JPEG.

Singkatnya, Anda mungkin tidak perlu terlalu khawatir tentang konversi ini. Namun, jika Anda pergi untuk mengarsipkan proyek Anda sebagai tarball, sesama pembuat kode mungkin akan lebih suka memiliki terminal LF daripada CRLF. Tergantung pada seberapa besar Anda peduli (dan tergantung pada Anda tidak menggunakan Notepad), Anda mungkin ingin mengatur git untuk menggunakan pengembalian LF jika Anda bisa :)

Lampiran: CR adalah kode ASCII 13, LF adalah kode ASCII 10. Jadi, CRLF adalah dua byte, sedangkan LF adalah satu.

Pastikan Anda telah menginstal git terbaru.
Saya melakukan seperti di atas git config core.autocrlf false, ketika menggunakan git (versi 2.7.1), tetapi tidak berhasil.
Maka itu berfungsi sekarang ketika memutakhirkan git (dari 2.7.1 ke 2.20.1).

1. Buka file di Notepad ++.
2. Pergi ke Edit / Konversi EOL.
3. Klik ke Format Windows.
4. Simpan file.

Pertanyaan OP terkait windows dan saya tidak bisa menggunakan yang lain tanpa masuk ke direktori atau bahkan menjalankan file di Notepad ++ karena administrator tidak berfungsi .. Jadi harus melalui rute ini:

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

Banyak editor teks memungkinkan Anda untuk berubah LF, lihat instruksi Atom di bawah ini. Sederhana dan eksplisit.

Klik CRLFdi kanan bawah:

Pilih LFdropdown di atas:

Dalam prompt shell GNU / Linux, perintah dos2unix & unix2dos memungkinkan Anda untuk dengan mudah mengkonversi / memformat file Anda yang berasal dari MS Windows

CRLF dapat menyebabkan beberapa masalah saat menggunakan "kode" Anda di dua OS yang berbeda (Linux dan Windows). Skrip python saya ditulis dalam wadah buruh pelabuhan Linux dan kemudian didorong menggunakan Windows git-bash. Itu memberi saya peringatan bahwa LF akan digantikan oleh CRLF. Saya tidak terlalu memikirkannya tetapi kemudian ketika saya memulai skrip nanti, katanya /usr/bin/env: 'python\r': No such file or directory. Sekarang \runtuk percabangan bagi Anda. Windows menggunakan "CR" - carriage return - di atas '\ n' sebagai karakter baris baru - \n\r. Itu sesuatu yang mungkin harus Anda pertimbangkan.

Sebagian besar alat di Windows hanya menerima LF dalam file teks. Sebagai contoh, Anda dapat mengontrol perilaku untuk Visual Studio dalam file bernama '.editorconfig' dengan konten contoh berikut (bagian):

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

Hanya Windows-Notepad asli yang tidak bekerja dengan LF tetapi ada beberapa alat editor sederhana yang lebih tepat tersedia!

Karenanya Anda harus menggunakan LF dalam file teks di Windows juga. Ini adalah pesan saya, sangat dianjurkan! Tidak ada alasan untuk menggunakan CRLF di windows!

(Diskusi yang sama menggunakan \ in include paths di C / ++, itu omong kosong, gunakan #include <pathTo / myheader.h> dengan slash !, Ini adalah standar C / ++ dan semua kompiler microsoft mendukungnya).

Maka pengaturan yang tepat untuk git adalah

git config core.autocrlf false

Pesan saya: Lupakan program berpikir lama seperti dos2unix dan unix2dos. Jelaskan dalam tim Anda bahwa LF layak digunakan di Windows.