Чому Git трактує цей текстовий файл як двійковий файл?

Цікаво, чому git мені це говорить:?

$ 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

Чи не текстові файли?

Я перевірив .gitattributes і він порожній. Чому я отримую це повідомлення? Я не можу отримати діффи, як раніше

ДОДАТО:

Я помітив, що @у файлі є дозволи, що це? Чи може це бути причиною?

$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

Це просто означає, що коли git перевіряє фактичний вміст файлу (він не знає, що будь-яке розширення не є двійковим файлом - ви можете використовувати файл атрибутів, якщо ви хочете сказати це явно - перегляньте сторінки man).

Оглянувши вміст файлу, він побачив матеріал, який не є основними символами ascii. Будучи UTF16, я очікую, що у нього будуть "смішні" персонажі, тому він вважає, що це двійкове.

Існують способи сказати git, якщо у вас є інтернаціоналізація (i18n) або розширені формати символів для файлу. Я недостатньо розглядаю точний метод для встановлення цього - можливо, вам знадобиться RT [Full] M ;-)

Редагувати: швидкий пошук SO знайденого can-i-make-git -pozna-a-utf-16-file-as-text тексту, який повинен дати вам декілька підказок.

Якщо ви не встановили тип файлу, Git намагається визначити його автоматично, а файл із дійсно довгими рядками і, можливо, деякі широкі символи (наприклад, Unicode) трактуються як двійкові. За допомогою файлу .gitattributes ви можете визначити, як Git інтерпретує файл. Встановлення атрибуту diff вручну дозволяє Git інтерпретувати вміст файлу як текст і зробить звичайний diff.

Просто додайте .gitattributes у кореневу папку вашого сховища та встановіть атрибут diff до шляхів чи файлів. Ось приклад:

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

Якщо ви хочете перевірити, чи є у файлі встановлені атрибути, це можна зробити за допомогою git check-attr

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

Ще одна приємна довідка про атрибути Git можна знайти тут .

У мене виникла ця проблема, коли Git GUI та SourceTree розглядали файли Java / JS як бінарні, і тому не міг побачити різницю

Створення файлу з назвою "атрибути" у папці .git \ info із наступним вмістом вирішило проблему

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

Якщо ви хочете внести цю зміну для всіх сховищ, тоді ви можете додати файл атрибутів у наступному розташуванні $ HOME / .config / git / attributes

Git навіть визначить, що він є двійковим, якщо у вашому текстовому файлі є один дуже довгий рядок. Я розірвав довгу рядок, перетворивши її на кілька рядків вихідного коду, і раптом файл перейшов із «двійкового» у текстовий файл, який я міг бачити (у SmartGit).

Тому не продовжуйте вводити занадто далеко вправо, не натискаючи "Enter" у своєму редакторі - інакше пізніше Git подумає, що ви створили двійковий файл.

У мене була ця сама проблема після редагування одного з моїх файлів у новому редакторі. Виявляється, новий редактор використовував інше кодування (Unicode), ніж мій старий редактор (UTF-8). Тому я просто сказав своєму новому редактору зберегти мої файли за допомогою UTF-8, а потім git знову показав свої зміни, і не бачив у ньому бінарний файл.

Я думаю, що проблема полягала лише в тому, що git не знає, як порівнювати файли різних типів кодування. Отже, тип кодування, який ви використовуєте, насправді не має значення, доки він залишається послідовним.

Я не перевіряв це, але я впевнений, якби я тільки що вчинив свій файл із новим кодуванням Unicode, наступного разу, коли я вносив би зміни до цього файлу, він би показав зміни належним чином і не визначив би його як бінарний, оскільки тоді було б порівняння двох файлів, кодованих Unicode, а не файлу UTF-8 з файлом Unicode.

Ви можете використовувати такий додаток, як Notepad ++, щоб легко переглядати та змінювати тип кодування текстового файлу; Відкрийте файл у «Блокноті ++» та скористайтеся меню «Кодування» на панелі інструментів.

У мене була така ж проблема. Я знайшов нитку під час пошуку рішення в google, все ще не знаходжу жодної підказки. Але я думаю, що я знайшов причину після вивчення, наступний приклад чітко пояснить мою підказку.

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

наразі файл new.txt розглядається як текстовий файл.

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

ви отримаєте цей результат

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

і спробуйте це

git diff -a

ви потрапите нижче

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

У нас був такий випадок, коли файл .html розглядався як двійковий всякий раз, коли ми намагалися внести зміни до нього. Дуже неохолоджене, щоб не бачити, відрізняється. Якщо чесно, я не перевірив усі рішення тут, але для нас спрацювало таке:

1. Вилучив файл (фактично перемістив його на мій робочий стіл) і започаткував git deletion. Гіт кажеDeleted file with mode 100644 (Regular) Binary file differs
2. Повторно додав файл (фактично перемістив його зі свого робочого столу назад у проект). Git каже, що New file with mode 100644 (Regular) 1 chunk, 135 insertions, 0 deletionsфайл тепер додається як звичайний текстовий файл

Відтепер будь-які зміни, внесені до файлу, розглядаються як звичайний текст. Ви також можете скинути ці зобов'язання (1, 2 і 3 - це фактична зміна, яку ви внесли), але я вважаю за краще мати можливість бачити в майбутньому те, що я зробив. Збивання 1 і 2 покаже бінарні зміни.

За цією корисною відповіддю ви можете прямо запитати Git, чому він обробляє файл певним чином:

cd directory/of/interest
file *

Це дає такий корисний результат:

$ 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

Це також викликано (принаймні в Windows) текстовими файлами, які мають UTF-8 з кодуванням BOM . Зміна кодування на звичайний UTF-8 негайно змусила Git бачити файл як type = text

У мене був екземпляр, де за призначенням .gitignoreмістилася подвійна \r(повернення каретки) послідовності.

Цей файл був визначений як двійковий за допомогою git. Додавання .gitattributesфайлу допомогло.

# .gitattributes file
.gitignore diff

Якщо git check-attr --all -- src/my_file.txtвказано, що ваш файл позначений як бінарний, і ви не встановили його як бінарний .gitattributes, перевірте його /.git/info/attributes.

Змініть Aux.js на інше ім’я, наприклад, Sig.js.

Дерево-джерело все ще показує його як двійковий файл, але ви можете його ставити (додавати) та виконувати.

У мене була подібна проблема, коли я вставляв текст із двійкового повідомлення Kafka, який вставляв невидимий символ і змушував git вважати, що файл є двійковим.

Я знайшов ображених персонажів, шукаючи файл за допомогою регексу [^ -~\n\r\t]+.

• [ відповідні символи в цьому наборі
• ^ відповідати символам, які не в цьому наборі
• -~ відповідає всім символам від "" (пробіл) до "~"
• \n новий рядок
• \r повернення вагона
• \t вкладка
• ] закрити набір
• + відповідати одному або декільком із цих символів

Я просто провів кілька годин, переглядаючи все, що в цьому списку, намагаючись розібратися, чому один із тестових проектів у моєму рішенні не додав жодних тестів досліднику.

У моєму випадку виявилося, що якось (можливо, через поганий злиття десь), VS втратив орієнтир проекту взагалі. Він ще будував, але я помітив, що він лише будував залежності.

Потім я помітив, що він не відображається у списку залежностей, тому я видалив і знову додав тестовий проект, і всі мої тести виявилися нарешті.