Как выяснить, почему файл был преобразован в GIT для преобразования в EOL? - PullRequest
Новая
       43

Как выяснить, почему файл был преобразован в GIT для преобразования в EOL?

0 голосов
/ 14 января 2019

Если в хранилище присутствует .gitattributes или для конфигурации конца строки (EOL) задан параметр конфигурации, git должен принять решение, является ли файл text или binary .

Иногда это решение не очевидно, например, если в файле присутствуют невидимые символы, см. https://confluence.atlassian.com/bbkb/file-detected-as-binary-not-displayed-as-text-in-bitbucket-892611499.html для примера.

Наличие символов, которые приводят к тому, что файл распознается как нечто, чем оно не является, - это то, что вы, возможно, захотите исправить в большинстве случаев. Однако анализ с использованием hexdump и vi, как предлагается в связанном посте, может быть исчерпывающим и для некоторых файлов и / или пользователей практически невозможен. Есть ли способ узнать, что заставляет git распознать файл как текст или двоичный файл в многословном материале (например, «преобразовать [путь] в двоичный файл из-за присутствия [некоторой кодовой точки] в строке [n]»)?

Наша команда использует Git 2.19 и 2.17 в Ubuntu 18.10, Windows 10 и macOS.

Ответы [ 2 ]

0 голосов
/ 15 января 2019

git ls-files --eol отображает информацию о том, как файлы идентифицируются git и как они фиксируются:

- EOL

Шоу и файлов. является идентификатором содержимого файла, используемым Git, когда атрибут «text» имеет значение «auto» (или не установлен, а core.autocrlf не равен false). это либо "-text", "none", "lf", "crlf", "mixed", либо "".

"" означает, что файл не является обычным файлом, его нет в индексе или он недоступен в рабочем дереве.

- это атрибут, который используется при извлечении или фиксации, это либо "", "-text", "text", "text = auto", "text eol = lf", "text eol = crlf". Так как в Git 2.10 поддерживаются "text = auto eol = lf" и "text = auto eol = crlf".

Как в индексе ("i /"), так и в рабочем дереве ("w /") отображаются обычные файлы, за которыми следует ("attr /").

из git ls-files документации

0 голосов
/ 14 января 2019

git полагается на buffer_is_binary в своем файле xdiff-interface.c , чтобы определить, является ли файл двоичным или текстовым. Эта функция вызывается из кода слияния Git, среди других мест. Логика проста - файл является двоичным, если в его первых 8000 байтах есть 0 байт. Код: 

#define FIRST_FEW_BYTES 8000
int buffer_is_binary(const char *ptr, unsigned long size)
{
    if (FIRST_FEW_BYTES < size)
        size = FIRST_FEW_BYTES;
    return !!memchr(ptr, 0, size);
}

Таким образом, у вас могут быть очень простые файлы, обнаруживаемые как двоичные, если они закодированы в UTF-16, что является распространенной причиной того, что Git рассматривает файлы как двоичные. Текстовый файл, содержащий 

a b

будет обнаружен как двоичный файл, если он будет сохранен в UTF-16, потому что его вывод hexdump имеет конец файла LF: 

0000000 6100 2000 6200 0a00

Например, пробел (0x20 в ASCII или UTF-8) кодируется как 0x0020 в UTF-16, поэтому Git рассматривает двоичный файл.

Так что «подробный» режим не очень поможет, так как вам нужно найти 0 байт. grep может сделать это в режиме Perl-regex, например grep -obaUP "\x00" filename, для печати смещений байтов 0 -значных байтов.

...