Что означает код проверки в документации git для окончаний строк?

Я действительно запутался, что означает «проверить код» на следующей странице: https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#__code_core_autocrlf_code

Если вы работаете на компьютере с Windows, установите для него значение true — это преобразует окончания LF в CRLF при проверке кода:

Это значит, когда вы добавляете файлы? Потому что всякий раз, когда я меняю core.autocrlf с input на true и наоборот, разница, которую я вижу, когда добавляю файлы (значит ли «извлечь» «добавить»?):

> git config --global core.autocrlf true

> git add crlf-file.md

> git add lf-file.md
 warning: LF will be replaced by CRLF in lf-file.md.
 The file will have its original line endings in your working directory.

> git config --global core.autocrlf input

> git add crlf-file.md
  warning: CRLF will be replaced by LF in crlf-file.md.
  The file will have its original line endings in your working directory.
> git add lf-file.md

git core.autocrlf gitattributes
person Marinos An    schedule 11.10.2017    source источник
comment
Если вы когда-либо использовали какой-либо вид контроля версий раньше, извлечение является довольно распространенным термином. Всякий раз, когда git обновляет файлы в вашем рабочем дереве, например, git checkout. Когда вы делаете git clone, он сначала копирует репозиторий (каталог .git), а затем проверяет соответствующую ветвь в вашем рабочем дереве.   -  person Mort    schedule 11.10.2017
comment
@Mort да, проверка часто используется, но VSS, SVN и Git имеют разные определения этого термина.   -  person crashmstr    schedule 11.10.2017
comment
git-checkout — переключение веток или восстановление файлов рабочего дерева   -  person crashmstr    schedule 11.10.2017

Ответы (3)


arrow_upward
5
arrow_downward

(Примечание: я пытаюсь ответить на основной вопрос, который, похоже, на самом деле звучит так: Если проверка означает git checkout, почему я получаю эти сообщения во время git add?)

Документация по этому поводу немного небрежна, возможно, намеренно, потому что точно правильные детали несколько неясны. Чтобы хорошо понять это на концептуальном уровне, вы должны рассматривать модификацию конца строки как часть более общей фильтрации smudge и clean (поскольку именно так она реализована ).

В Git каждый файл, с которым вы можете работать в данный момент, существует одновременно в трех местах:

the HEAD commit      the index       the work-tree
---------------      ---------       -------------
README.md            README.md       README.md
file.txt             file.txt        file.txt

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

(Вы также можете сделать новую фиксацию из индекса. При этом старая фиксация HEAD остается в покое, а новая фиксация становится фиксацией HEAD. Таким образом, после создания новой фиксации, фиксация HEAD и индекс совпадают. Это не потому, что мы изменили какую-либо фиксацию; мы не можем этого сделать. Это потому, что мы добавили новую фиксацию, сделанную из индекса, а затем перестали вызывать старый фиксирует HEAD и вместо этого вызывает новый HEAD.)

Обратите внимание, что индекс находится «на пути» между HEAD и рабочим деревом. Чтобы скопировать любой файл из HEAD в рабочее дерево, он должен сначала пройти через индекс. Чтобы сделать новую фиксацию из рабочего дерева, каждый новый файл должен пройти через индекс. Следовательно, переходы между индексом и рабочим деревом — это место, где происходят очистка и размазывание.

«Очистить» файл означает подготовить его к фиксации. Этот процесс очистки может, например, преобразовать окончания строк CRLF в окончания строк только LF. Или, используя фильтр ident, вы можете отменить множество замен или написать свой собственный фильтр, чтобы делать практически все что угодно. Размазать файл означает подготовить его для редактирования и/или использования в рабочем дереве. Это может, например, преобразовать окончания строк только LF в окончания CRLF. Как и в случае с процессом очистки, вы можете использовать фильтр ident или свой собственный фильтр-драйвер, чтобы делать все, что захотите. Git LFS использует эти драйверы для замены коротких ссылок и всего содержимого файла.

Следовательно, точный ответ заключается в том, что преобразования конца строки применяются во время тех процессов, которые копируют файлы в индекс или из него. Наиболее распространены эти два:

  • git add копирует из рабочего дерева в индекс.
  • git checkout извлекается в рабочее дерево либо из фиксации в индекс, а затем в рабочее дерево, либо прямо из индекса в рабочее дерево.

Любое из этих преобразований CRLF-to-LF или LF-to-CRLF происходит только в это время. Но в Git есть дополнительный код, который пытается интуитивно понять, приведут ли эти преобразования позже к изменению существующих зафиксированных данных, даже если они еще не были выполнены. Этот код выдаст предупреждающие сообщения, которые вы видите:

warning: LF will be replaced by CRLF ...
warning: CRLF will be replaced by LF ...

Эти предупреждения появляются, если вы включаете опцию «безопасный crlf». Поскольку они происходят из разных кодов, запускаемых в разное время, все может быть очень запутанным.

person torek    schedule 11.10.2017

arrow_upward
2
arrow_downward

Обратите внимание, что эти предупреждения о преобразовании в конце строки, отображаемые, когда core.safecrlf установлено на true или warn, не всегда будет работать при оформлении заказа, так как он может неправильно срабатывать для содержимого, которое не использует CRLF в качестве окончания строки.

Это было исправлено в Git 2.16 (1 квартал 2018 г.)

См. коммит 649f1f0 (8 декабря 2017 г.) и коммит 86ff70a (26 ноября 2017 г.), автор Торстен Бегерсхаузен (tboegi).
(Объединено Юнио С. Хамано -- gitster -- в commit 720b176, 27 декабря 2017 г.)

convert: ужесточить безопасную обработку autocrlf

Когда текстовый файл был зафиксирован с помощью CRLF, а файл снова зафиксирован, CRLF сохраняется, если .gitattributs имеет "text=auto".
Это делается путем анализа содержимого большого двоичного объекта, хранящегося в индексе: если '\r' найден, Git предполагает, что большой двоичный объект был зафиксирован с помощью CRLF.

Простой поиск '\r' не всегда работает должным образом:
Файл закодирован в UTF-16 с CRLF и зафиксирован. Git рассматривает его как двоичный файл.
Теперь содержимое преобразуется в кодировку UTF-8. При следующем коммите Git обрабатывает файл как текст, CRLF должен быть преобразован в LF, но это не так.

Замените has_cr_in_index() на has_crlf_in_index(). Если '\r' не найдено, возвращается 0, это наиболее распространенный случай.
Если найден '\r', содержимое анализируется более глубоко.

person VonC    schedule 28.12.2017

arrow_upward
0
arrow_downward

Рассмотрим библиотеку. Когда вы берете книгу из библиотеки, ни один другой посетитель не может получить к ней доступ, пока вы не вернете ее обратно.

Старые централизованные системы контроля версий работали аналогично; когда вы «извлекали» файл, система блокировала этот файл, и ни один другой пользователь не мог извлечь тот же файл, пока вы не вернули его обратно.

Более новые системы управления версиями, как правило, позволяют нескольким пользователям работать с файлом одновременно, требуя объединения несовместимых изменений, а не строгой сериализации доступа к файлу. Тем не менее, термин «извлечение» по-прежнему используется для обозначения процесса копирования файла из репозитория в ваш рабочий каталог.

person chepner    schedule 11.10.2017