git LF yerine CRLF koymak

Git'i bir Windows XP makinesinde bash kullanarak çalıştırma. Projemi SVN'den ihraç ettim ve daha sonra çıplak bir depoyu klonladım.

Sonra ihracat çıplak depolar dizinine yapıştırdı ve bir yaptım:

git add -A

Daha sonra şu mesajların bir listesini aldım:

LF'nin yerini CRLF alacak

Bu dönüşümün sonuçları nelerdir? Bu, Visual Studio'da bir .NET çözümüdür.

Bu iletiler, core.autocrlfWindows'taki yanlış varsayılan değerinden kaynaklanıyor .

Kavramı, autocrlfsatır sonları dönüşümlerini şeffaf bir şekilde ele almaktır. Ve öyle!

Kötü haber : değerin manuel olarak yapılandırılması gerekir.
İyi haber : git kurulum başına yalnızca bir kez yapılmalıdır (proje ayarlarına göre de mümkündür).

Nasıl autocrlfçalışır :

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

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

Burada crlf= galibiyet stili satır sonu işareti, lf= unix stili (ve mac osx).

(pre-osx crin yukarıdaki üç seçenekten hiçbirinden etkilenmez)

Bu uyarı ne zaman görünüyor (Windows altında)

    - autocrlf= dosyalarınızdan birinde trueunix stiliniz varsa lf(= Nadiren),
    - autocrlf= dosyalarınızdan birinde inputkazanma stiliniz varsa crlf(= neredeyse HER ZAMAN),
    - autocrlf= false- ASLA!

Bu uyarı ne anlama geliyor?

Uyarı " LF CRLF ile değiştirilecektir " Eğer (sahip olduğunu söylüyor autocrlf= trueişlemek-çıkış döngüsü (o pencere tarzı CRLF yerini alacaktır) sonra unix tarzı LF kaybolur). Git, pencerelerin altında unix tarzı LF kullanmanızı beklemiyor.

Uyarı " CRLF LF ile değiştirilecektir " Eğer (sahip olduğunu söylüyor autocrlf= inputa (o Unix tarzı LF ile değiştirilecektir) döngüsü-çıkış tamamlamak sonra windows tarzı CRLF kaybolur). inputPencerelerin altında kullanmayın .

Nasıl autocrlfçalıştığını göstermenin başka bir yolu

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

burada x ya CRLF (windows tarzı) veya LF (unix tarzı) ve oklar

file to commit -> repository -> checked out file

Nasıl düzeltilir

core.autocrlfGit kurulumu sırasında varsayılan değer seçilir ve sistem genelinde gitconfig ( %ProgramFiles(x86)%\git\etc\gitconfig) içinde saklanır . Ayrıca (aşağıdaki sırayla basamaklı) var:

   - adresinde bulunan "küresel" (kullanıcı başına) gitconfig ~/.gitconfig, henüz başka
   - at "global" (kullanıcı başına) gitconfig $XDG_CONFIG_HOME/git/configveya $HOME/.config/git/configve
   kısmındaki "Yerel" (başına repo) gitconfig - .git/configçalışma dir.

Bu nedenle, git config core.autocrlfşu anda kullanılan değeri kontrol etmek için çalışma dizinine yazın ve

   - eklenti autocrlf=falsesistem genelinde gitconfig # başına sistemine çözümüne
   - git config --global core.autocrlf false            # kullanıcı başına çözüm
   - git config --local core.autocrlf false              # Herbir proje çözümü

Uyarılar
- git configayarlar, gitattributesayarlar tarafından geçersiz kılınabilir .
- crlf -> lfdönüştürme yalnızca yeni dosyalar eklenirken gerçekleşir, crlfdepoda zaten mevcut olan dosyalar etkilenmez.

Ahlaki (Windows için):
    - use core.autocrlf= truebu projeyi Unix altında da kullanmayı planlıyorsanız (ve editör / IDE'nizi unix satır sonlarını kullanacak şekilde yapılandırmak istemiyorsanız),
    - use core.autocrlf= falsebu projeyi yalnızca Windows altında kullanmayı planlıyorsanız ( veya düzenleyicinizi / IDE'nizi unix satır sonlarını kullanacak şekilde yapılandırdıysanız),
    - iyi bir nedeniniz yoksa ( örneğin , pencerelerin altında unix yardımcı programları kullanıyorsanız veya makefiles sorunlarıyla karşılaşıyorsanız) aslacore.autocrlf = kullanmayın ,input

PS Windows için git'i yüklerken ne seçilmeli?
Unix altındaki projelerinizden hiçbirini kullanmayacaksanız , varsayılan ilk seçeneği kabul etmeyin . Üçüncü olanı seçin ( Olduğu gibi ödeme yapın, olduğu gibi işleme koyun ). Bu mesajı görmeyeceksiniz. Hiç.

PPS Benim kişisel tercih yapılandırıyor editör / IDE Unix tarzı uçlarını kullanmaya ve ayar core.autocrlfiçin false.

Git'in satır sonlarını nasıl ele alacağına dair üç modu vardır:

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

Kullanılacak modu ek bir parametre ekleyerek ayarlayabilirsiniz. truefalseYukarıdaki komut satırına veya .

Eğer core.autocrlf taahhüt içinde onu saklar önce git düşündüğü git repo dosya eklemek her zaman bir metin dosyasıdır araçlarının, sadece LF tüm CRLF satır sonları dönecek, true olarak ayarlanır. Ne zaman bir git checkoutşey yaparsanız , tüm metin dosyaları otomatik olarak LF satır sonlarına CRLF sonlarına dönüştürülür. Bu, bir projenin satır sonlandırma stili her zaman tutarlı bir şekilde LF olduğu için her bir editör satır bitiş stilini değiştirdiğinden, taahhütler olmadan farklı satır sonu stilleri kullanan platformlar arasında bir projenin geliştirilmesine izin verir.

Bu uygun dönüşümün yan etkisi ve gördüğünüz uyarı budur, orijinal olarak yazdığınız bir metin dosyasının CRLF yerine LF sonları varsa, her zamanki gibi LF ile saklanacağı, ancak kontrol edildiğinde daha sonra CRLF sonları olacaktır. Normal metin dosyaları için bu genellikle iyidir. Uyarı bu durumda bir "bilginiz için" dir, ancak git yanlış bir ikili dosyayı bir metin dosyası olarak değerlendirirse, önemli bir uyarıdır çünkü git daha sonra ikili dosyanızı bozar.

Eğer core.autocrlffalse olarak ayarlanır metin dosyaları olduğu gibi teslim edilir, böylece hiçbir satır bitmeyen dönüşüm hiç gerçekleştirilir. Tüm geliştiricileriniz Linux veya tümü Windows'ta olduğu sürece bu genellikle işe yarar. Ancak tecrübelerime göre, yine de karışık satır sonlarına sahip metin dosyaları elde etme eğilimindeyim.

Kişisel tercihim, ayarı bir Windows geliştiricisi olarak AÇIK bırakmaktır.

"Girdi" değerini içeren güncellenmiş bilgiler için http://kernel.org/pub/software/scm/git/docs/git-config.html adresine bakın .

Kodu zaten kontrol ettiyseniz, dosyalar zaten dizine eklenir. Git ayarlarınızı değiştirdikten sonra şunu söyleyerek çalıştırın:

git config --global core.autocrlf input 

ile dizinleri yenilemelisiniz

git rm --cached -r . 

git git dizinini

git reset --hard

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

Not: Bu, yerel değişikliklerinizi kaldıracaktır, bunu yapmadan önce saklamayı düşünün.

git config core.autocrlf false

Hem Unix2Dos ve dos2unix gitbash pencereler mevcuttur. UNIX (LF) -> DOS (CRLF) dönüşümünü gerçekleştirmek için aşağıdaki komutu kullanabilirsiniz. Bu nedenle, uyarıyı alamazsınız.

unix2dos filename

veya

dos2unix -D filename

Ancak, bu komutu varolan herhangi bir CRLF dosyasında çalıştırmayın, her ikinci satırda boş satırlar alırsınız.

dos2unix -D filenameher işletim sistemiyle çalışmaz. Lütfen uyumluluk için bu bağlantıyı kontrol edin .

Herhangi bir nedenle komutu zorlamanız gerekiyorsa kullanın --force. Geçersiz yazıyorsa kullanın -f.

@ Basiloungas'ın yanıtı yakın ama güncel değil (en azından Mac'te).

~ / .Gitconfig dosyasını açın ve safecrlffalse olarak ayarlayın

[core]
       autocrlf = input
       safecrlf = false

Bu * satır sonu karakterini görmezden gelecektir (zaten benim için çalıştı).

Bir satır sonları üzerinde Github makalesi bu konu hakkında konuşurken sık söz edilir.

Sık önerilen core.autocrlfyapılandırma ayarını kullanma konusundaki kişisel deneyimim çok karışıktı.

Windows'u Cygwin ile birlikte kullanıyorum, farklı zamanlarda hem Windows hem de UNIX projeleriyle uğraşıyorum. Windows projelerim bile bazen bashUNIX (LF) satır sonları gerektiren kabuk komut dosyaları kullanır .

GitHub'ın core.autocrlfWindows için önerilen ayarını kullanarak , bir UNIX projesine (Cygwin'de mükemmel bir şekilde çalışır - veya belki de Linux sunucumda kullandığım bir projeye katkıda bulunuyorsam), metin dosyaları Windows ile kontrol edilir (CRLF) ) satır sonları, sorunlar yaratır.

Temel olarak, benim gibi karışık bir ortam için, küresel core.autocrlfolanı seçeneklerden herhangi birine ayarlamak bazı durumlarda iyi çalışmaz. Bu seçenek yerel (depo) git config üzerinde ayarlanmış olabilir, ancak bu hem Windows hem de UNIX ile ilgili şeyler içeren bir proje için yeterince iyi olmaz (örneğin, bazı bashyardımcı program komut dosyalarına sahip bir Windows projem var ).

Bulduğum en iyi seçenek, havuz başına .gitattributes dosyaları oluşturmaktır . GitHub makale bunu bahseder.
Bu makaleden bir örnek:

# 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

Projemin deposundan birinde:

* 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

Kurmak biraz daha fazla şey, ancak proje başına bir kez yapın ve herhangi bir işletim sistemindeki herhangi bir katılımcı, bu proje ile çalışırken hat sonlarıyla ilgili herhangi bir sorun yaşamamalıdır.

Vim'de dosyayı açın (örneğin:) :e YOURFILEENTER, ardından

:set noendofline binary
:wq

Ben de bu problemi yaşadım.

SVN herhangi bir satır sonu dönüşümü yapmaz, bu nedenle dosyalar CRLF satır sonlarıyla bozulmadan işlenir. Daha sonra projeyi git'e koymak için git-svn komutunu kullanırsanız, CRLF uçları git deposunda kalır, bu da git'in kendisini bulmayı beklediği durum değildir - varsayılan değer yalnızca unix / linux (LF) satır sonlarına sahip olmaktır kontrol edilmiş.

Daha sonra dosyaları Windows'ta kontrol ettiğinizde, autocrlf dönüşümü dosyaları olduğu gibi bırakır (geçerli platform için zaten doğru sonlara sahip oldukları için), ancak teslim edilen dosyalarla bir fark olup olmadığına karar veren işlem ters dönüşümü gerçekleştirir karşılaştırmadan önce , ne düşündüğünü karşılaştırmak, teslim alınan dosyadaki bir LF'nin depoda beklenmeyen bir CRLF ile karşılaştırılmasıyla sonuçlanır.

Bildiğim kadarıyla seçimleriniz:

1. Git-svn kullanmadan kodunuzu yeni bir git deposuna yeniden içe aktarın, bu satır sonlarının intial git commit --all içinde dönüştürüldüğü anlamına gelir
2. Autocrlf öğesini false olarak ayarlayın ve satır sonlarının git'in tercih ettiği stilde olmadığı gerçeğini göz ardı edin
3. Autocrlf kapalıyken dosyalarınızı kontrol edin, tüm satır sonlarını düzeltin, her şeyi tekrar kontrol edin ve tekrar açın.
4. Orijinal işlemin artık git'in beklemediği CRLF'yi içermemesi için havuzunuzun geçmişini yeniden yazın. (Tarih yeniden yazma ile ilgili olağan uyarılar geçerlidir)

Dipnot: # 2 seçeneğini belirlerseniz, deneyimim, yardımcı araçların bazılarının (rebase, patch vb.) CRLF dosyalarıyla başa çıkmayacağı ve er ya da geç CRLF ve LF (tutarsız çizgi) karışımı olan dosyalarla sonuçlanacaksınız. uçları). İkisinden de en iyi şekilde yararlanmanın bir yolunu bilmiyorum.

Aşağıdakileri ~ / .gitattributes dosyasından kaldırma

* text=auto

git'in ilk etapta satır sonlarını kontrol etmesini engelleyecektir.

Bunu şöyle olmalıdır:

uyarı: ( Mevcut çekirdeğinizle başka bir klasöre göz atarsanız / veya kopyalarsanıztrue , LF'nin yerini CRLF alır

Dosya ( geçerli ) çalışma dizininizde orijinal satır sonlarına sahip olacaktır .

Bu resim ne anlama geldiğini açıklamalıdır.

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

echo "* -crlf" > .gitattributes 

Bunu ayrı bir işlemde yapın veya git, tek bir değişiklik yaptığınızda tüm dosyaları değiştirilmiş olarak görebilir (autocrlf seçeneğini değiştirip değiştirmediğinize bağlı olarak)

Bu gerçekten işe yarıyor. Git, karma hat bitirme projelerinde hat sonlarına saygı gösterecek ve sizi bunlar hakkında uyarmayacaktır.

Windows'ta git hakkında çok şey bilmiyorum, ama ...

Bana git'in çalışan formatın (Windows) formatına uyması için dönüş formatını dönüştürdüğü anlaşılıyor. CRLF, Windows'ta varsayılan dönüş biçimidir, LF ise diğer işletim sistemlerinin çoğu için varsayılan dönüş biçimidir.

Büyük olasılıkla, kod başka bir sisteme taşındığında dönüş biçimi düzgün şekilde ayarlanır. Ben de git, örneğin JPEG'lerde LF'leri CRLF'lere dönüştürmeye çalışmak yerine ikili dosyaları sağlam tutacak kadar akıllı olduğunu düşünüyorum.

Özetle, bu dönüşümden çok fazla endişelenmenize gerek yoktur. Ancak, projenizi bir tarball olarak arşivlemeye giderseniz, diğer kodlayıcılar muhtemelen CRLF yerine LF hat sonlandırıcılarına sahip olmaktan memnun olacaktır. Ne kadar önemsediğinize bağlı olarak (ve Not Defteri'ni kullanmamanıza bağlı olarak), eğer mümkünse git'i LF iadelerini kullanacak şekilde ayarlamak isteyebilirsiniz :)

Ek: CR, ASCII kodu 13, LF, ASCII kodu 10'dur. Bu nedenle, CRLF iki bayt, LF birdir.

En son git'i yüklediğinizden emin olun. Git (sürüm 2.7.1) kullanıldığında
yukarıdaki git config core.autocrlf falsegibi yaptım, ama işe yaramadı.
O zaman şimdi git git (2.7.1'den 2.20.1'e) olduğunda çalışır.

1. Dosyayı Notepad ++ ile açın.
2. Düzenle / EOL Dönüşümüne gidin.
3. Windows Formatına tıklayın.
4. Dosya 'yı kaydet.

OP sorusu windows ile ilgili ve ben dizine gitmeden veya yönetici işe yaramadı olarak Notepad ++ bile dosya çalıştırmadan başkalarını kullanamadı. Bu yüzden bu yolu gitmek zorunda kaldı:

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

Birçok metin düzenleyici, değiştirmenize izin verir LF, aşağıdaki Atom talimatlarına bakın. Basit ve açık.

CRLFSağ alt kısma tıklayın :

LFÜst taraftaki açılır menüden seçin :

GNU / Linux kabuk isteminde, dos2unix & unix2dos komutları MS Windows'dan gelen dosyalarınızı yavaşça dönüştürmenizi / biçimlendirmenizi sağlar

CRLF, iki farklı işletim sisteminde (Linux ve Windows) "kodunuzu" kullanırken bazı sorunlara neden olabilir. Python betiğim Linux docker kapsayıcısına yazılmış ve sonra Windows git-bash kullanılarak aktarılmıştır. Bana LF'nin yerini CRLF alacağı uyarısı verdi. Çok düşünmedim ama senaryoya daha sonra başladığımda, dedi /usr/bin/env: 'python\r': No such file or directory. Şimdi \rsenin için bir yaklaştırma için. Windows, "CR" - satır başı - '\ n' üstünde yeni satır karakteri olarak - kullanıyor \n\r. Bu dikkate almanız gerekebilecek bir şey.

Windows'taki araçların çoğu metin dosyalarında yalnızca LF'yi kabul eder. Örneğin, '.editorconfig' adlı bir dosyada Visual Studio'nun davranışını aşağıdaki örnek içerikle (bölüm) kontrol edebilirsiniz:

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

Sadece orijinal Windows Not Defteri LF ile çalışmaz, ancak daha uygun bazı basit editör araçları vardır!

Bu nedenle, Windows'taki metin dosyalarında da LF kullanmalısınız. Bu benim mesajım, şiddetle tavsiye edilir! Windows'ta CRLF kullanmak için bir sebep yok!

(Aynı tartışma C / ++ 'daki path'lerde \ kullanıyor, saçmalık, eğik çizgi ile #include <pathTo / myheader.h> kullanın !, C / ++ standardıdır ve tüm microsoft derleyiciler bunu destekler).

Dolayısıyla git için doğru ayar

git config core.autocrlf false

Mesajım: dos2unix ve unix2dos gibi eski düşünme programlarını unutun. Ekibinizde LF'nin Windows altında kullanmaya uygun olduğunu açıklayın.