Git neden bu metin dosyasına ikili dosya olarak davranıyor?

Acaba git neden bana bunu söylüyor :?

$ git diff MyFile.txt
diff --git a/MyFile.txt b/MyFile.txt
index d41a4f3..15dcfa2 100644
Binary files a/MyFile.txt and b/MyFile.txt differ

Metin dosyaları değil mi?

Ben .gitattributes kontrol ettim ve boş. Bu mesajı neden alıyorum? Artık kullandığım için fark alamıyorum

KATMA:

@Dosya izinlerinde bir tane olduğunu fark ettim , bu nedir? Nedeni bu olabilir mi?

$ls -all
drwxr-xr-x   5 nacho4d  staff    170 28 Jul 17:07 .
drwxr-xr-x  16 nacho4d  staff    544 28 Jul 16:39 ..
-rw-r--r--@  1 nacho4d  staff   6148 28 Jul 16:15 .DS_Store
-rw-r--r--@  1 nacho4d  staff    746 28 Jul 17:07 MyFile.txt
-rw-r--r--   1 nacho4d  staff  22538  5 Apr 16:18 OtherFile.txt

Bu sadece git dosyanın gerçek içeriğini incelediğinde (herhangi bir uzantının ikili bir dosya olmadığını bilmediği anlamına gelir - açıkça söylemek isterseniz öznitelikler dosyasını kullanabilirsiniz - man sayfalarına bakın).

Dosyanın içeriğini inceledikten sonra temel ascii karakterlerinde olmayan şeyler gördü. UTF16 olarak 'komik' karakterlere sahip olmasını bekliyorum, bu yüzden ikili olduğunu düşünüyor.

Dosya için uluslararasılaştırma (i18n) veya genişletilmiş karakter biçimleriniz varsa git'i söylemenin yolları vardır. Bunu ayarlamak için tam yöntem üzerinde yeterince değilim - RT [Full] M ;-) gerekebilir

Düzenleme: SO bulundu can-i-make-git-recognize-a-utf-16-dosya-metin olarak size birkaç ipucu vermelidir hızlı bir arama .

Bir dosyanın türünü ayarlamadıysanız, Git bunu otomatik olarak belirlemeye çalışır ve gerçekten uzun hatları ve belki bazı sahip bir dosya geniş karakterler (örn Unicode) ikili olarak ele alınır. İle .gitattributes Eğer Git dosyayı yorumlayabildiğini nasıl tanımlayabilirsiniz dosya. Diff özelliğinin manuel olarak ayarlanması Git'in dosya içeriğini metin olarak yorumlamasına ve normal bir fark yapmasına izin verir.

Havuz kök klasörünüze bir .gitattributes ekleyin ve diff özniteliğini yollara veya dosyalara ayarlayın. İşte bir örnek:

src/Acme/DemoBundle/Resources/public/js/i18n/* diff
doc/Help/NothingToSay.yml                      diff
*.css                                          diff

Bir dosyada ayarlanan öznitelik olup olmadığını kontrol etmek istiyorsanız, git check-attr yardımı ile bunu yapabilirsiniz.

git check-attr --all -- src/my_file.txt

Git özellikleriyle ilgili bir başka hoş referans burada bulunabilir .

Git GUI ve SourceTree'nin Java / JS dosyalarını ikili olarak ele aldığı ve bu nedenle farkı göremediği bu sorunu yaşıyordum

Aşağıdaki içeriğe sahip .git \ info klasöründe "öznitelikler" adlı bir dosya oluşturmak sorunu çözdü

*.java diff
*.js diff
*.pl diff
*.txt diff
*.ts diff
*.html diff

Bu değişikliği tüm depolar için yapmak isterseniz, şu konuma $ HOME / .config / git / attributes özniteliği dosyası ekleyebilirsiniz.

Git, metin dosyanızda bir tane çok uzun satır varsa, bunun ikili olduğunu bile belirleyecektir. Birkaç kaynak kodu satırına çevirerek uzun bir dize kırdı ve aniden dosya 'ikili' olmaktan görebildiğim bir metin dosyasına (SmartGit) gitti.

Bu yüzden editörünüzde 'Enter' tuşuna basmadan sağa çok fazla yazmaya devam etmeyin - aksi takdirde Git'te bir ikili dosya oluşturduğunuzu düşünür.

Dosyalarımdan birini yeni bir düzenleyicide düzenledikten sonra da aynı sorunu yaşadım. Yeni düzenleyicinin eski düzenleyicimden (UTF-8) farklı bir kodlama (Unicode) kullandığı ortaya çıktı. Bu yüzden yeni editörüme dosyalarımı UTF-8 ile kaydetmesini söyledim ve git değişiklikleriimi tekrar düzgün bir şekilde gösterdi ve ikili dosya olarak görmedi.

Sorun sadece git farklı kodlama türleri dosyaları karşılaştırmak bilmiyor olduğunu düşünüyorum. Bu nedenle, kullandığınız kodlama türü tutarlı kaldığı sürece gerçekten önemli değildir.

Test etmedim, ancak yeni Unicode kodlamasıyla dosyamı işlemiş olsaydım eminim, bir dahaki sefere bu dosyada değişiklik yaptığımda değişiklikleri düzgün bir şekilde gösterecek ve ikili olarak algılanmayacaktı, çünkü UTF-8 dosyasını Unicode dosyasıyla değil, iki Unicode kodlu dosyayı karşılaştırırdı.

Bir metin dosyasının kodlama türünü kolayca görmek ve değiştirmek için Notepad ++ gibi bir uygulama kullanabilirsiniz ; Dosyayı Notepad ++ ile açın ve araç çubuğundaki Kodlama menüsünü kullanın.

Aynı problemim vardı. Google'da çözüm ararken ipliği buldum, yine de hiçbir ipucu bulamıyorum. Ama çalıştıktan sonra sebebini bulduğumu düşünüyorum, aşağıdaki örnek ipucumu net bir şekilde açıklayacaktır.

    echo "new text" > new.txt
    git add new.txt
    git commit -m "dummy"

şimdilik, new.txt dosyası bir metin dosyası olarak kabul edilmektedir.

    echo -e "newer text\000" > new.txt
    git diff

bu sonucu alacaksın

diff --git a/new.txt b/new.txt
index fa49b07..410428c 100644
Binary files a/new.txt and b/new.txt differ

ve bunu dene

git diff -a

aşağıya ineceksin

    diff --git a/new.txt b/new.txt
    index fa49b07..9664e3f 100644
    --- a/new.txt
    +++ b/new.txt
    @@ -1 +1 @@
    -new file
    +newer text^@

Değişiklik yapmaya çalıştığımızda bir .html dosyasının ikili olarak görüldüğü bu durum vardı. Farkları görmemek için çok soğuk. Dürüst olmak gerekirse, burada tüm çözümleri kontrol etmedim ama bizim için işe yarayan şey şuydu:

1. Dosya kaldırıldı (aslında masaüstüme taşındı) ve git deletion. Git diyorDeleted file with mode 100644 (Regular) Binary file differs
2. Dosyayı yeniden ekledim (aslında Masaüstümden projeye geri taşıdım). Git, New file with mode 100644 (Regular) 1 chunk, 135 insertions, 0 deletionsdosya artık normal bir metin dosyası olarak eklendiğini söylüyor

Şu andan itibaren, dosyada yaptığım herhangi bir değişiklik normal bir metin farkı olarak görülüyor. Bu taahhütleri de (1, 2 ve 3, yaptığınız gerçek değişiklik olarak) ezebilirsiniz, ancak gelecekte ne yaptığımı görmeyi tercih ederim. Ezme 1 ve 2 ikili bir değişiklik gösterecektir.

Bu yararlı yanıt başına Git'e bir dosyayı neden belirli bir şekilde ele aldığını doğrudan sorabilirsiniz:

cd directory/of/interest
file *

Bunun gibi yararlı çıktılar üretir:

$ file *
CR6Series_stats resaved.dat: ASCII text, with very long lines, with CRLF line terminators
CR6Series_stats utf8.dat:    UTF-8 Unicode (with BOM) text, with very long lines, with CRLF line terminators
CR6Series_stats.dat:         ASCII text, with very long lines, with CRLF line terminators
readme.md:                   ASCII text, with CRLF line terminators

Bu da (en azından Windows'ta) BOM kodlamalı UTF-8 içeren metin dosyalarından kaynaklanır . Kodlamayı normal UTF-8 olarak değiştirmek, Git'in dosyayı type = text olarak görmesini sağladı

Ben amaca göre .gitignorebir çift \r(satır başı) dizisi içeren bir örneği vardı .

Bu dosya git tarafından ikili olarak tanımlandı. Bir .gitattributesdosya eklemek yardımcı oldu.

# .gitattributes file
.gitignore diff

Eğer git check-attr --all -- src/my_file.txtdosya ikili olarak işaretlendiğinde, ve ikili in olarak ayarlamak bulunmadığını ima .gitattributesbunun için, çek /.git/info/attributes.

Aux.js dosyasını Sig.js gibi başka bir adla değiştirin.

Kaynak ağaç yine de bir ikili dosya olarak gösterir, ancak bunu sahne alabilir (ekleyebilir) ve kaydedebilirsiniz.

Ben görünür olmayan bir karakter ekledi ve git dosya ikili olduğunu düşünmesine neden ikili Kafka mesajından bazı metin yapıştırdığımda benzer bir sorun vardı.

Ragex kullanarak dosyayı arayarak rahatsız edici karakterler buldum [^ -~\n\r\t]+.

• [ bu setteki karakterlerle eşleş
• ^ bu sette olmayan karakterlerle eşleş
• -~ '' (boşluk) ile '~' arasındaki tüm karakterlerle eşleşir
• \n Yeni hat
• \r satırbaşı
• \t çıkıntı
• ] seti kapat
• + bu karakterlerden bir veya daha fazlasıyla eşleş

Çözümümdeki test projelerinden birinin neden explorer'a herhangi bir test eklemediğini bulmaya çalışmak için bu listedeki her şeyi inceleyerek birkaç saat geçirdim.

Benim durumumda, bir şekilde (muhtemelen bir yerlerde zayıf git birleştirme nedeniyle) VS'nin projeyi tamamen bir referans kaybettiği ortaya çıktı. Hâlâ inşa ediyordu ama sadece bağımlılıkları inşa ettiğini fark ettim.

Daha sonra bağımlılıklar listesinde görünmediğini fark ettim, bu yüzden test projesini kaldırdım ve yeniden ekledim ve tüm testlerim sonunda ortaya çıktı.