Почему Git обрабатывает этот текстовый файл как двоичный файл?

Ответ 1

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

Проверяя содержимое файла, он увидел материал, который не имеет базовых символов ascii. Будучи UTF16, я ожидаю, что у него будут "смешные" персонажи, поэтому он будет считать его двоичным.

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

Изменить: быстрый поиск SO нашел can-i-make-git-recognize-a-utf-16-file-as-text, который должен дать вам несколько подсказок.

Ответ 2

Если вы не задали тип файла, 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 можно найти здесь.

Ответ 3

Git даже определит, что он двоичный, если у вас есть одна сверхдолгая строка в текстовом файле. Я разбил длинную строку, превратив ее в несколько строк исходного кода, и внезапно файл перешел от "двоичного" к текстовому файлу, который я мог видеть (в SmartGit).

Так что не набирайте слишком далеко вправо, не нажимая 'Enter' в свой редактор, иначе в дальнейшем Git подумает, что вы создали двоичный файл.

Ответ 4

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

Создание файла с именем "attributes" в .git\info папке со следующим содержимым разрешило проблему

*.java diff
*.js diff
*.pl diff
*.txt diff

Если вы хотите сделать это изменение для всех репозиториев, вы можете добавить файл атрибутов в следующем месте $ HOME/.config/ git/атрибуты

Ответ 5

У меня возникла такая же проблема после редактирования одного из моих файлов в новом редакторе. Оказывается, новый редактор использовал другую кодировку (Unicode), чем мой старый редактор (UTF-8). Поэтому я просто сказал своему новому редактору сохранить мои файлы с помощью UTF-8, а затем git снова показал мои изменения и не видел его как двоичный файл.

Я думаю, проблема была в том, что git не знает, как сравнивать файлы разных типов кодирования. Таким образом, тип кодировки, который вы используете, действительно не имеет значения, если он остается согласованным.

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

Вы можете использовать приложение типа Notepad ++, чтобы легко видеть и изменять тип кодировки текстового файла; Откройте файл в Notepad ++ и используйте меню "Кодировка" на панели инструментов.

Ответ 6

У меня была такая же проблема. Я нашел поток при поиске решения в 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^@

Ответ 7

У нас был этот случай, когда файл .html рассматривался как двоичный, когда мы пытались внести в него изменения. Очень неудобно, чтобы не видеть различий. Честно говоря, я не проверял все решения здесь, но то, что сработало для нас, было следующим:

• Убрал файл (фактически переместил его на рабочий стол) и совершил git deletion. Git говорит Deleted file with mode 100644 (Regular) Binary file differs
• Повторно добавлен файл (фактически перемещен это с моего рабочего стола обратно в проект). Git говорит New file with mode 100644 (Regular) 1 chunk, 135 insertions, 0 deletions Файл теперь добавляется как обычный текстовый файл

Отныне любые изменения, внесенные мной в файл, рассматриваются как обычный текстовый diff. Вы также можете раздавить эти коммиты (1, 2 и 3 - это фактическое изменение, которое вы делаете), но я предпочитаю видеть в будущем то, что я сделал. Скрипты 1 и 2 показывают двоичное изменение.

Ответ 8

Столкнулась с аналогичной проблемой в .java файлах. В моем случае проблема возникла из-за наличия специальных символов.

Просьба проверить наличие специальных символов в файлах.

Ответ 9

Per этот полезный ответ, вы можете напрямую спросить 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

Ответ 10

Я просто провел несколько часов, пройдя все в этом списке, пытаясь понять, почему один из тестовых проектов в моем решении не добавлял никаких тестов в проводник.

В моем случае оказалось, что каким-то образом (вероятно, из-за плохого слияния git) VS полностью потерял ссылку на проект. Он все еще строился, но я заметил, что он только построил зависимости.

Затем я заметил, что он не отображался в самом списке зависимостей, поэтому я удалил и повторно добавил тестовый проект, и все мои тесты появились наконец.