Dlaczego Git traktuje ten plik tekstowy jako plik binarny?

Zastanawiam się, dlaczego git mi to mówi :?

$ 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

Czy nie są to pliki tekstowe?

Sprawdziłem .gitattributes i jest pusty. Dlaczego otrzymuję tę wiadomość? Nie mogę już uzyskać różnic, tak jak używam

DODANY:

Zauważyłem, że @w pliku są uprawnienia, co to jest? Czy to może być powód?

$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

Oznacza to po prostu, że kiedy git sprawdza rzeczywistą zawartość pliku (nie wie, że żadne dane rozszerzenie nie jest plikiem binarnym - możesz użyć pliku atrybutów, jeśli chcesz to wyraźnie powiedzieć - zobacz strony podręcznika).

Po sprawdzeniu zawartości pliku zobaczył rzeczy, które nie są w podstawowych znakach ascii. Będąc UTF16, spodziewam się, że będzie miał „zabawne” postacie, więc uważa, że ​​jest binarny.

Istnieją sposoby, aby powiedzieć gitowi, czy masz internacjonalizację (i18n) lub rozszerzone formaty znaków dla pliku. Nie mam wystarczającej wiedzy na temat dokładnej metody ustawienia tego - być może będziesz musiał RT [Full] M ;-)

Edycja: szybkie wyszukiwanie znalezionego SO can-i-make-git-aware-a-utf-16-file-as-text, co powinno dać ci kilka wskazówek.

Jeśli nie ustawiłeś typu pliku, Git spróbuje określić go automatycznie i plik z naprawdę długimi liniami i być może kilka szerokich znaków (np. Unicode) jest traktowany jako binarny. Za pomocą pliku .gitattributes możesz zdefiniować, w jaki sposób Git interpretuje plik. Ręczne ustawienie atrybutu diff pozwala Gitowi zinterpretować zawartość pliku jako tekst i wykona zwykłe porównanie.

Po prostu dodaj .gitattributes do głównego folderu repozytorium i ustaw atrybut diff na ścieżki lub pliki. Oto przykład:

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

Jeśli chcesz sprawdzić, czy plik ma ustawione atrybuty, możesz to zrobić za pomocą git check-attr

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

Kolejne fajne odniesienie do atrybutów Git można znaleźć tutaj .

Miałem ten problem, w którym Git GUI i SourceTree traktowały pliki Java / JS jako binarne i dlatego nie widziałem różnicy

Utworzenie pliku o nazwie „attributes” w folderze .git \ info z następującą zawartością rozwiązało problem

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

Jeśli chcesz wprowadzić tę zmianę dla wszystkich repozytoriów, możesz dodać plik atrybutów w następującej lokalizacji $ HOME / .config / git / attributes

Git ustali nawet, że jest binarny, jeśli masz jedną bardzo długą linię w pliku tekstowym. Zerwałem długi ciąg znaków, zamieniając go na kilka linii kodu źródłowego i nagle plik zmienił się z binarnego w plik tekstowy, który widziałem (w SmartGit).

Więc nie pisz zbyt daleko w prawo bez naciskania „Enter” w edytorze - w przeciwnym razie Git pomyśli, że utworzyłeś plik binarny.

Miałem ten sam problem po edycji jednego z moich plików w nowym edytorze. Okazuje się, że nowy edytor używał innego kodowania (Unicode) niż mój stary edytor (UTF-8). Więc po prostu powiedziałem mojemu nowemu edytorowi, aby zapisał moje pliki w UTF-8, a następnie git ponownie pokazał moje zmiany i nie zobaczył tego jako pliku binarnego.

Myślę, że problem polegał na tym, że git nie wie, jak porównać pliki o różnych typach kodowania. Tak więc typ kodowania, którego używasz, naprawdę nie ma znaczenia, o ile pozostaje spójny.

Nie testowałem tego, ale jestem pewien, że gdybym po prostu zatwierdził mój plik z nowym kodowaniem Unicode, następnym razem, gdybym wprowadził zmiany w tym pliku, pokazałby zmiany poprawnie i nie wykryłby go jako binarnego, ponieważ wtedy porównywałoby dwa pliki zakodowane w Unicode, a nie plik UTF-8 z plikiem Unicode.

Możesz użyć aplikacji takiej jak Notepad ++, aby łatwo zobaczyć i zmienić typ kodowania pliku tekstowego; Otwórz plik w Notepad ++ i użyj menu Kodowanie na pasku narzędzi.

Miałem ten sam problem. Znalazłem wątek, szukając rozwiązania w Google, nadal nie znajduję żadnej wskazówki. Ale myślę, że znalazłem powód po przestudiowaniu, poniższy przykład wyjaśni jasno moją wskazówkę.

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

na razie plik nowy.txt jest traktowany jako plik tekstowy.

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

otrzymasz ten wynik

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

i spróbuj tego

git diff -a

dostaniesz się poniżej

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

Mieliśmy taki przypadek, w którym plik .html był postrzegany jako binarny za każdym razem, gdy próbowaliśmy wprowadzić w nim zmiany. Bardzo niefajne, aby nie widzieć różnic. Szczerze mówiąc, nie sprawdziłem tutaj wszystkich rozwiązań, ale zadziałało u nas następujące:

1. Usunąłem plik (faktycznie przeniosłem go na mój pulpit) i zatwierdziłem git deletion. Mówi GitDeleted file with mode 100644 (Regular) Binary file differs
2. Ponownie dodałem plik (faktycznie przeniosłem go z mojego pulpitu z powrotem do projektu). Git mówi, że New file with mode 100644 (Regular) 1 chunk, 135 insertions, 0 deletionsplik jest teraz dodawany jako zwykły plik tekstowy

Odtąd wszelkie zmiany, które wprowadziłem w pliku, są widoczne jako zwykłe różnice tekstowe. Możesz również zmiażdżyć te zatwierdzenia (1, 2 i 3 to faktyczna zmiana, którą wprowadzasz), ale wolę móc zobaczyć w przyszłości, co zrobiłem. Zgniatanie 1 i 2 pokaże zmianę binarną.

Korzystając z tej przydatnej odpowiedzi , możesz bezpośrednio zapytać Gita, dlaczego traktuje plik w określony sposób:

cd directory/of/interest
file *

Daje użyteczne dane wyjściowe, takie jak:

$ 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

Jest to również spowodowane (przynajmniej w systemie Windows) plikami tekstowymi z kodowaniem UTF-8 z kodowaniem BOM . Zmiana kodowania na zwykłe UTF-8 natychmiast sprawiła, że ​​Git zobaczył plik jako type = text

Miałem przypadek, w którym celowo .gitignorezawierał podwójną \rsekwencję (powrót karetki).

Ten plik został zidentyfikowany jako binarny przez git. Dodanie .gitattributespliku pomogło.

# .gitattributes file
.gitignore diff

Jeśli git check-attr --all -- src/my_file.txtwskazuje, że plik jest oflagowany jako binarny, a nie ustawiłeś go jako binarny .gitattributes, sprawdź, czy jest w nim /.git/info/attributes.

Zmień Aux.js na inną nazwę, na przykład Sig.js.

Drzewo źródłowe nadal przedstawia go jako plik binarny, ale można go umieścić na etapie (dodać) i zatwierdzić.

Miałem podobny problem, gdy wkleiłem tekst z binarnej wiadomości Kafki, która wstawiła niewidoczny znak i spowodowała, że ​​git pomyślał, że plik jest binarny.

Znalazłem obraźliwe znaki, przeszukując plik za pomocą wyrażenia regularnego [^ -~\n\r\t]+.

• [ dopasuj znaki w tym zestawie
• ^ dopasuj znaki spoza tego zestawu
• -~ dopasowuje wszystkie znaki od „” (spacja) do „~”
• \n Nowa linia
• \r powrót karetki
• \t patka
• ] zamknij zestaw
• + dopasuj jeden lub więcej z tych znaków

Właśnie spędziłem kilka godzin przeglądając wszystko z tej listy, próbując zrozumieć, dlaczego jeden z projektów testowych w moim rozwiązaniu nie dodał żadnych testów do eksploratora.

Okazało się w moim przypadku, że w jakiś sposób (prawdopodobnie z powodu złego gdzieś scalania gitów), że VS całkowicie stracił odniesienie do projektu. Wciąż się budował, ale zauważyłem, że budował tylko zależności.

Potem zauważyłem, że nie pojawia się on na samej liście zależności, więc usunąłem i ponownie dodałem projekt testowy i wszystkie moje testy wreszcie się pojawiły.