Satır sonu dönüşümleri git core.autocrlf ile farklı işletim sistemleri arasında nasıl çalışır?

Stack Overflow'un yanı sıra core.autocrlf ayarının nasıl çalıştığına dair git belgelerinde birçok farklı soru ve cevap okudum .

Okuduğum şeyden bu benim anlayışım:

Unix ve Mac OSX (OSX öncesi CR kullanır) istemciler LF satır sonlarını kullanır.
Windows istemcileri CRLF satır sonlarını kullanır.

Core.autocrlf istemcide true değerine ayarlandığında, git deposu her zaman LF satır sonu biçiminde dosyaları depolar ve istemcideki dosyalardaki satır sonları, teslim alma / tamamlama özelliğini kullanan istemciler (örn. Windows) için ileri geri dönüştürülür -LF satır sonları, satır sonları dosyalarının istemcide hangi formatta olduğuna bakılmaksızın (bu Tim Clem'in tanımına katılmamaktadır - aşağıdaki güncellemeye bakınız).

Burada, core.autocrlf 'satır' dönüşüm 'satır sonu dönüşüm davranış emin değilim' giriş 've' yanlış 'ayarları için aynı belgelemek için çalışan bir matris.

Sorularım:

1. Soru işaretleri ne olmalı?
2. Bu matris "soru olmayan işaretler" için doğru mu?

Uzlaşma oluşmuş gibi göründüğü için cevaplardaki soru işaretlerini güncelleyeceğim.

                       core.autocrlf değeri
            doğru giriş yanlış
-------------------------------------------------- --------
taahhüt | dönüştürmek? ?
yeni | - LF (LF'ye dönüştür?) (dönüşüm yok?)

taahhüt | e dönüşmek ? Hayır
mevcut | LF (LF'ye dönüştürme?) Dönüşümü

ödeme | e dönüşmek ? Hayır
mevcut | CRLF (dönüşüm yok mu?) Dönüşümü

Gerçekten çeşitli ortamların artıları ve eksileri hakkında görüş aramıyorum. Sadece git'in üç ayarın her biri ile çalışmasını nasıl beklediğini netleştiren verileri arıyorum.

-

Güncelleme 04/17/2012 : yorumlarda JJD ile bağlantılı Tim Clem'in makalesini okuduktan sonra , yukarıdaki tabloda "bilinmeyen" değerlerin bazı değerlerini değiştirdim ve mevcut "check out to true" değiştirdim msgstr "CRLF yerine istemciye dönüştür". İşte başka yerlerde gördüğüm her şeyden daha açık olan tanımları:

core.autocrlf = yanlış

Bu varsayılan ayardır, ancak çoğu insan bunu hemen değiştirmeye teşvik edilir. False kullanmanın sonucu Git'in dosyanızdaki satır sonlarıyla hiç uğraşmamasıdır. LF veya CRLF veya CR içeren dosyaları teslim edebilirsiniz veya bu üçünün rasgele bir karışımını kullanabilirsiniz ve Git umursamaz. Bu, farkların okunmasını zorlaştırabilir ve birleştirmeyi daha zor hale getirebilir. Unix / Linux dünyasında çalışan çoğu insan bu değeri kullanır çünkü CRLF sorunları yoktur ve dosyalar nesne veritabanına yazıldığında veya çalışma dizinine yazıldığında Git'in fazladan iş yapmasına gerek yoktur.

core.autocrlf = doğru

Bu, Git'in tüm metin dosyalarını işleyeceği ve bu dosyayı nesne veritabanına yazarken CRLF'nin LF ile değiştirildiğinden ve çalışma dizinine yazarken tüm LF'yi tekrar CRLF'ye dönüştürdüğü anlamına gelir. Bu, Windows'ta önerilen ayardır, çünkü çalışma dizininizde CRLF'yi tutarken deponuzun diğer platformlarda kullanılabilmesini sağlar.

core.autocrlf = giriş

Bu Git'in tüm metin dosyalarını işleyeceği ve bu dosyayı nesne veritabanına yazarken CRLF'nin LF ile değiştirildiğinden emin olacağı anlamına gelir. Ancak bunun tersini yapmayacaktır. Dosyaları nesne veritabanından geri okuduğunuzda ve çalışma dizinine yazdığınızda, satır sonunu göstermek için hala LF'leri olacaktır. Bu ayar genellikle Unix / Linux / OS X'te CRLF'lerin depoya yazılmasını önlemek için kullanılır. Bir web tarayıcısından kod yapıştırdıysanız ve yanlışlıkla dosyalarınızdan birine CRLF'ler eklediyseniz Git, nesne veritabanına yazdığınızda bunların LF'lerle değiştirildiğinden emin olur.

Tim'in makalesi mükemmel, eksik olduğunu düşünebileceğim tek şey, deponun özellikle sadece Windows projeleri için mutlaka doğru olmayan LF formatında olduğunu varsayıyor.

Tim'in makalesini jmlane tarafından bugüne kadarki en yüksek oylanan cevapla karşılaştırmak, doğru ve giriş ayarları üzerinde mükemmel bir anlaşma ve yanlış ayar üzerinde anlaşmazlık gösterir.

core.autocrlfİşlerin nasıl yapıldığına dair en iyi açıklama , nitelikler kılavuz sayfasında, textözellik bölümünde bulunur.

Bu nasıl core.autocrlf(Farkındayım ne v1.7.2 beri ya da en azından) görünür şu anda çalışmak için:

• core.autocrlf = true
  1. Depodan yalnızca LFkarakter içeren metin dosyaları CRLF, çalışma ağacınızda normalleştirilir ; CRLFdepoda bulunan dosyalara dokunulmaz
  2. Sadece var Metin dosyaları LFdepoda karakterleri, gelen normalize edilir CRLFiçin LFdeposuna zaman kararlı arka. Havuzda bulunan dosyalara CRLFdokunulmaz.
• core.autocrlf = input
  1. Depodan teslim alınan metin dosyaları orijinal EOL karakterlerini çalışma ağacınızda tutar.
  2. Çalışma ağacınızdaki CRLFkarakter içeren metin dosyaları LF, depoya geri gönderildiklerinde normalleştirilir .
• core.autocrlf = false
  1. core.eol çalışma ağacınızın metin dosyalarındaki EOL karakterlerini belirler.
  2. core.eol = nativevarsayılan olarak, Windows EOL'leri CRLFve * nix EOL'ları LFçalışma ağaçlarındadır.
  3. Havuz gitattributesayarları, depodaki taahhütler için EOL karakter normalleştirmesini belirler (varsayılan, LFkarakterlerin normalleştirilmesidir ).

Kısa bir süre önce bu konuyu araştırdım ve durumu çok kıvrımlı buluyorum. core.eolAyar kesinlikle EOL karakterler git ile nasıl işlendiğini açıklamak yardımcı oldu.

Karma platformlu projelerde EOL sorunu uzun zamandır hayatımı perişan ediyor. Sorunlar genellikle repoda zaten farklı ve karışık EOL'lere sahip dosyalar olduğunda ortaya çıkar . Bunun anlamı şudur ki:

1. Repo'nun farklı EOL'lere sahip farklı dosyaları olabilir
2. Repo Bazı dosyalar bir arada örneğin, karışık EOL sahip olabilir CRLFve LFaynı dosyada.

Bunun nasıl olduğu burada sorun değil, ama oluyor.

Çeşitli modlar ve kombinasyonları için Windows'ta bazı dönüşüm testleri yaptım.
İşte biraz değiştirilmiş bir tabloda var:

                 | Ne zaman sonuç dönüşümü | Sonuçta dönüşüm
                 | çeşitli dosya işleme | depodan kontrol -
                 | EOL'lar depoya giriş ve | içinde karışık dosyalar bulunan ve
                 | core.autocrlf değeri: | core.autocrlf değeri:           
-------------------------------------------------- ------------------------------
Dosya | gerçek | girdi | yanlış | gerçek | girdi | yanlış
-------------------------------------------------- ------------------------------
Windows-CRLF | CRLF -> LF | CRLF -> LF | olduğu gibi | olduğu gibi | olduğu gibi | gibi kullanıldı
Unix -LF | olduğu gibi | olduğu gibi | olduğu gibi | LF -> CRLF | olduğu gibi | gibi kullanıldı
Mac -CR | olduğu gibi | olduğu gibi | olduğu gibi | olduğu gibi | olduğu gibi | gibi kullanıldı
Karışık-CRLF + LF | olduğu gibi | olduğu gibi | olduğu gibi | olduğu gibi | olduğu gibi | gibi kullanıldı
Karışık-CRLF + LF + CR | olduğu gibi | olduğu gibi | olduğu gibi | olduğu gibi | olduğu gibi | gibi kullanıldı

Gördüğünüz gibi, tamamlamada dönüşüm gerçekleştiğinde 2 durum vardır (3 sol sütun). Diğer durumlarda dosyalar olduğu gibi işlenir.

Ödeme yapıldıktan sonra (3 sağ sütun), dönüşümün şu durumlarda gerçekleştiği yalnızca 1 durum vardır:

1. core.autocrlfolduğu true ve
2. depodaki dosyada LFEOL vardır.

Benim için en şaşırtıcı ve şüpheliyim ki, birçok EOL probleminin nedeni, karışık EOL benzeri CRLF+ 'nın LFnormalleştiği bir yapılandırma olmamasıdır .

Ayrıca sadece "eski" Mac EOLs CRasla dönüştürülmez unutmayın.
Bu, kötü yazılmış bir EOL dönüşüm komut dosyası, CRLFs + LFs ile karışık bir bitiş dosyasını dönüştürmeye çalışırsa , yalnızca LFs'yi CRLFs'ye dönüştürerek , dosyanın CRa CRLFdönüştürüldüğü her yerde "yalnız" s ile karışık modda bırakacağı anlamına gelir CRCRLF.
Git, truemodda bile hiçbir şeyi dönüştürmeyecek ve EOL tahribatı devam ediyor. Bu aslında başıma geldi ve bazı editörler ve derleyiciler (örneğin VS2010) Mac EOL'leri sevmediği için dosyalarımı çok kötü bir şekilde karıştırdı.

Bu sorunları gerçekten ele almanın tek yolu , tüm dosyaları veya modda kontrol ederek , uygun bir normalleştirme çalıştırarak ve değiştirilen dosyaları (varsa) yeniden gerçekleştirerek zaman zaman tüm repoyu normalleştirmek. Windows'da, muhtemelen çalışmaya devam edin .inputfalsecore.autocrlf true

Yaklaşan Git 1.7.2 ile "eol dönüşümü" cephesinde bazı şeyler değişmek üzere :

Yeni bir yapılandırma ayarı core.eolekleniyor / geliştiriliyor :

Bu, core.eolşu anda pu( dizimdeki sonuncu) bulunan 'Ekle " " yapılandırma değişkeni "taahhüdünün yerine geçer .
Bunun yerine "olduğunu ima ait core.autocrlf=true" yerine geçer " * text=auto", bu açık gerçeği yapar autocrlfmetin dosyası normalleşmesini olmayan bir depo üzerindeki çalışma dizinindeki CRLFlerin ile çalışmak isteyen kullanıcılar içindir .
Etkinleştirildiğinde, "core.eol" yoksayılır.

core.eolKullanıcının çalışma dizinindeki satır sonu normalize edilmiş dosyalar için hangi satır sonlarının kullanılacağını ayarlamasına olanak tanıyan yeni bir yapılandırma değişkeni " " girin.
Varsayılan olarak " native", Windows'ta CRLF ve diğer her yerde LF anlamına gelir. " core.autocrlf" Geçersiz kıldığını unutmayın core.eol.
Bunun anlamı şudur ki:

[core]
  autocrlf = true

core.eol" lf" olarak ayarlanmış olsa bile CRLF'leri çalışma dizinine yerleştirir .

core.eol:

textÖzelliği ayarlanmış dosyalar için çalışma dizininde kullanılacak satır sonu türünü ayarlar .
Alternatifler, platformun yerel satır sonunu kullanan 'lf', 'crlf' ve 'native' dir.
Varsayılan değer şudur native.

Diğer evrimler de dikkate alınmaktadır :

1.8 için, ben yapım dikkate alacağını core.autocrlfsadece normalleşme açıp core.eol kararı biten çalışma dizini hattını terk, ama bu olacak insanların kurulumları bölünürler.

git 2.8 (Mart 2016) core.autocrlfeol'ü etkileme yolunu iyileştirir :

Bkz. Taahhüt 817a0c7 (23 Şub 2016), taahhüt 6e336a5 , taahhüt df747b8 , taahhüt df747b8 (10 Şub 2016), taahhüt df747b8 , taahhüt df747b8 ( taahhüt 10d 2016) ve taahhüt 4b4024f , taahhüt bb211b4 , taahhüt 92cce13 , taahhüt 320d39c , taahhüt 4b4024f , taahhüt 4b4024f taahhüt bb211b4 , taahhüt 92cce13 , taahhüt 320d39c (05 Şub 2016) Torsten Bögershausen ( tboegi) .
^{(Göre Birleştirilmiş Junio Cı Hamano - gitster- içinde c6b94eb tamamlama, 26 Şub 2016)}

convert.c: refactor crlf_action

Yeniden belirleme ve kullanımı crlf_action.
Bugün, crlfbir dosyada hiçbir " " özniteliği ayarlanmadığında, crlf_actionolarak ayarlanır CRLF_GUESS. CRLF_UNDEFINEDBunun yerine kullanın ve daha önce olduğu gibi " text" veya " eol" için arama yapın .

Eski CRLF_GUESSkullanımı değiştirin :

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

Aşağıdakileri tanımlayarak daha net, neyin ne olduğunu açıklayın:

- 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)

As torek ekler yorumlarda :

tüm bu çeviriler (herhangi bir EOL dönüşümü eol=veya autocrlfayarlar ve " clean" filtreler) dosyalar çalışma ağacından dizine , yani zaman git addyerine hareket ettiğinde çalıştırılırgit commit .
(Bu Not git commit -aveya --onlyya --includeda, o zaman endeksine eklenti dosyaları yapın.)

Daha fazla bilgi için, bkz. " Autocrlf ve eol arasındaki fark nedir ".

core.autocrlfdeğeri işletim sistemi türüne bağlı değildir, ancak Windows varsayılan değeri trueLinux ve Linux için geçerlidir input. Taahhüt ve ödeme vakaları için 3 olası değeri araştırdım ve sonuçta ortaya çıkan tablo:

╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ 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 ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝

İşte birisine yardım etmesi durumunda şimdiye kadar benim anlayışım.

core.autocrlf=true ve core.safecrlf = true

Tüm satır sonlarının aynı olduğu bir havuzunuz var , ancak farklı platformlarda çalışıyorsunuz. Git, satır sonlarınızın platformunuz için varsayılana dönüştürülmesini sağlar. Bu neden önemli? Yeni bir dosya oluşturduğunuzu varsayalım. Platformunuzdaki metin düzenleyicisi varsayılan satır sonlarını kullanacaktır. Check-in yaptığınızda, core.autocrlf öğesi true olarak ayarlanmamışsa, platformdaki biri için varsayılan olarak farklı bir satır sonunu tutarsız tutarsız bir satır eklediniz. Ben de her zaman safecrlf ayarladım çünkü crlf işleminin tersine çevrilebilir olduğunu bilmek istiyorum. Bu iki ayarla, git dosyalarınızı değiştirir, ancak değişikliklerin geri alınabilir olduğunu doğrular .

core.autocrlf=false

Zaten karışık satır sonlarını kontrol etmiş bir havuzunuz var ve yanlış satır sonlarını düzeltmek başka şeyleri kırabilir. Bu durumda git'e satır sonlarını dönüştürmesini söylememek en iyisidir, çünkü o zaman çözmek için tasarlandığı sorunu daha da kötüleştirecektir - diffs'yi okumayı kolaylaştırır ve daha az acı verici hale getirir. Bu ayar ile git dosyalarınızı değiştirmez .

core.autocrlf=input

Bunu kullanmıyorum çünkü bunun nedeni, LF satır sonlarına varsayılan bir platformda CRLF satır sonlarına sahip bir dosya oluşturduğunuz kullanım durumunu kapsamaktır. Metin düzenleyicimin her zaman yeni dosyaları platformun satır sonu varsayılanlarıyla kaydetmesini tercih ederim.

Hayır, @jmlane yanıtı yanlış.

Şunun için Checkin (git add, git commit):

1. eğer textözelliktir Set, Set value to 'auto', dönüşüm dosyası 'CRLF' ile taahhüt edilmiştir trk olur
2. eğer textmülk ise Unset: hiçbir şey olmaz, enenCheckout
3. eğer textözelliktir Unspecified, dönüşüm bağlıdırcore.autocrlf
   1. eğer autocrlf = input or autocrlf = trueo 'CRLF' olduysa depoda dosya, 'LF' olduğunda, dönüşüm sadece olur, hiçbir şey irade olmuyor.
   2. eğer autocrlf = falsehiçbir şey olmazsa

Şunun için Checkout:

1. eğer textözelliktir Unset: hiçbir şey olmuyor.
2. eğer textözelliktir Set, Set value to 'auto: o bağlıdır core.autocrlf, core.eol.
   1. core.autocrlf = giriş: hiçbir şey olmuyor
   2. core.autocrlf = true: dönüşüm yalnızca havuzdaki dosya 'LF', 'LF' -> 'CRLF' olduğunda gerçekleşir
   3. core.autocrlf = false: dönüştürme yalnızca havuzdaki dosya 'LF', 'LF' olduğunda gerçekleşir -> core.eol
3. eğer textözelliktir Unspecified, bu bağlıdır core.autocrlf.
   1. aynı 2.1
   2. aynı 2.2
   3. Yok, hiçbir şey olmuyor, core.eol etkili değil textözelliktirUnspecified

Varsayılan davranış

Standart davranıştır Yani textözelliktir Unspecifiedve core.autocrlf = false:

1. check-in için hiçbir şey olmuyor
2. ödeme için hiçbir şey olmuyor

Sonuçlar

1. eğer textmülkiyet ayarlanır, davranış olduğunu kontrol ediyorum autocrlf üzerine, kendi üzerine değil bağlıdır
2. autocrlf veya core.eol ödeme davranışı içindir ve autocrlf> core.eol

Linux ve pencerelerde bazı testler yaptık. LF ile biten satırları ve ayrıca CRLF ile biten satırları içeren bir test dosyası kullanıyorum.
Dosya işlenir, kaldırılır ve sonra teslim alınır. Core.autocrlf değeri taahhütten önce ve ödeme yapmadan önce ayarlanır. Sonuç aşağıda.

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