Git'te neden core.autocrlf = true kullanmalıyım?

Hem Windows hem de OS X'ten erişilen bir Git depom var ve zaten CRLF satır sonlarına sahip bazı dosyalar içerdiğini biliyorum. Anlayabildiğim kadarıyla, bununla başa çıkmanın iki yolu var:

1. Set core.autocrlfiçin falseher yerde,

2. Yönergeleri izleyin burada sadece LF line-sonları içerecek şekilde depoyu dönüştürmek için (Github yardım sayfalarında yankılandı) ve daha sonra ayarlamak core.autocrlfiçin trueWindows üzerinde ve inputbunu yaparken ile sorun OS X'te olduğu Depodaki herhangi ikili dosyaları varsa o:

   1. gitattributes'da doğru olarak ikili olarak işaretlenmezse ve
   2. hem CRLF'leri hem de LF'leri içerir,

   bozulacaklar. Depomun bu tür dosyalar içermesi mümkündür.

Öyleyse neden Git'in satır sonu dönüşümünü kapatmamalıyım? Web'de core.autocrlfsorunlara neden olanları kapatmayla ilgili çok fazla belirsiz uyarı var , ancak çok az spesifik uyarı var; Şimdiye kadar bulduğum tek şey, kdiff3'ün CRLF sonlarını (benim için sorun değil) işleyememesi ve bazı metin editörlerinin satır sonu sorunları (benim için de sorun değil) olmasıdır.

Depo şirketimin içindedir ve bu nedenle farklı autocrlf ayarları veya satır sonu gereksinimleri olan kişilerle paylaşma konusunda endişelenmem gerekmez.

Satır sonlarını olduğu gibi bırakmamda başka sorun var mı?

Kümesine yalnızca belirli nedenler autocrlfiçin trueşunlardır:

• Unix tabanlı bir EOL Git repo'yu Windows'a kopyalarken yapılan otomatik EOL dönüşümü nedeniyle git statustüm dosyalarınızı göstermekten kaçının modified( örneğin 83. sayfaya bakın)
• ve kodlama araçlarınız bir şekilde dosyanızda bulunan yerel bir EOL stiline bağlıdır :
  • örneğin, yerel EOL'yi algılamak için sabit kodlanmış bir kod üreteci
  • normal EOL'yi algılamak için regexp veya kod ayarlı diğer harici gruplar (repo'nuzun dışında)
  • Bazı Eclipse eklentilerinin platformda ne olursa olsun CRLF ile dosya üretebileceğine inanıyorum, bu bir sorun olabilir.
  • Notepad.exe ile kod yazarsınız (Notepad'in algılanan EOL karakterine uyduğu bir Windows 10 2018.09+ kullanmıyorsanız ).

Belirli bir tedavi görebilirsiniz sürece gerekir yerli EOL başa, sen daha iyi durumda bırakarak autocrlfiçinfalse ( git config --global core.autocrlf false).

Bu yapılandırmanın yerel bir yapılandırma olacağını unutmayın (çünkü yapılandırma depodan depoya aktarılmaz)

O repo klonlama tüm kullanıcılar için aynı yapılandırma istiyorsanız "check out en iyisi nedir CRLFgit ile taşıma stratejisi? " Kullanılarak textöznitelik .gitattributesdosyası .

Misal:

*.vcproj    text eol=crlf
*.sh        text eol=lf

Not: git 2.8 (Mart 2016) 'dan başlayarak, birleştirme işaretleri artık bir CRLF dosyasında karışık satır sonu (LF) kullanmayacak.
Bkz: " <<<<<<< BAŞ‘birleştirme çizgileri onun üzerinde Git kullanımı CRLF yap’ "

Ben bir .NET geliştiricisiyim ve Git ve Visual Studio'yu yıllardır kullanıyorum. Benim güçlü tavsiyem, satır sonlarını doğru olarak ayarlamaktır. Ve Deponuzun ömrü boyunca olabildiğince erken yapın.

Bununla birlikte, Git'in satır sonlarımı değiştirmesinden nefret ediyorum. Bir kaynak kontrolü sadece yaptığım işi kaydetmeli ve almalı, DEĞİŞTİRMEMELİDİR. Hiç. Ama öyle.

Her geliştiriciyi true değerine ayarlamazsanız ne olur, ONE geliştiricisi sonunda true değerine ayarlanır. Bu, deponuzdaki tüm dosyalarınızın satır sonlarını LF olarak değiştirmeye başlayacaktır. Kullanıcılar bunları kontrol etmek için yanlış ayarladığında, Visual Studio sizi uyarır ve değiştirmenizi ister. Çok hızlı bir şekilde 2 şey olacak. Birincisi, bu uyarıların gittikçe daha fazlasını alacaksınız, takımınız ne kadar büyük olursa o kadar fazla alırsınız. İkinci ve daha da kötüsü, değiştirilen her dosyanın her satırının değiştiğini gösterecektir (çünkü her satırın satır sonları gerçek adam tarafından değiştirilecektir). Sonunda repodaki değişiklikleri artık güvenilir bir şekilde izleyemeyeceksiniz. Herkesin doğru kalmasını sağlamak, herkesi yanlış tutmaya çalışmaktan çok daha kolay ve temizdir. Güvenilir kaynak kontrolünüzün yapmaması gereken bir şey yapıyor olması gerçeği ile yaşamak kadar korkunç. Hiç.

Güncelleme 2 :

Xcode 9, dosyanın geçerli satır sonlarını yoksayacak bir "özelliğe" sahip gibi görünüyor ve bunun yerine, bir dosyaya satır eklerken varsayılan satır sonu ayarınızı kullanarak karışık satır sonlarına sahip dosyalara neden oluyor.

Eminim bu hata Xcode 7'de yoktu; Xcode 8'den emin değilim. İyi haber şu ki, Xcode 10'da düzeltilmiş gibi görünüyor.

Varolduğu süre boyunca, bu hata, soruda bahsettiğim kod tabanında (bu güne kadar kullanılan autocrlf=false) küçük bir miktar komikliğe neden oldu ve birçok "EOL" taahhüt mesajına ve nihayetinde pre-commitkontrol etmek için bir git kancasını yazmaya neden oldu karışık satır sonlarının girilmesi / önlenmesi için.

Güncelleme :

Not: As Git 2.8 başlayarak VonC tarafından da belirtildiği, birleştirme belirteçleri olacak değil , bir Windows tarzı dosyasına Unix tarzı satır sonları tanıtmak .

Orijinal :

Bu kurulumla fark ettiğim küçük bir hıçkırık, birleştirme çakışmaları olduğunda, git farklarını işaretlemek için eklenen satırların , dosyanın geri kalanı olsa bile Windows satır sonlarına sahip olmaması ve sonlandırmanızdır. karışık satır sonlarına sahip bir dosya ile, örneğin:

// Some code<CR><LF>
<<<<<<< Updated upstream<LF>
// Change A<CR><LF>
=======<LF>
// Change B<CR><LF>
>>>>>>> Stashed changes<LF>
// More code<CR><LF>

Bu bize herhangi bir soruna neden olmaz (her iki satır sonunu da ele alabilecek herhangi bir aracın karışık satır sonlarıyla da mantıklı olacağını düşünürüm - kesinlikle kullandığımız her şey yapar), ancak farkında olunması gereken bir şey.

Bulduğumuz diğer bir şey ^*git diff , Windows satır sonlarına sahip bir dosyadaki değişiklikleri görüntülemek için kullanıldığında , eklenen satırların satır başlarını görüntülemesidir, böylece:

    // Not changed

+   // New line added in^M
+^M
    // Not changed
    // Not changed

_{* "Sorun" terimini hak etmiyor.}