Git статус игнорировать измененные окончания строки - PullRequest
0 голосов
/ 17 апреля 2020

Я борюсь с git и игнорирую окончания строк. Об этом уже миллион раз спрашивали на SO, но я до сих пор не могу понять это для моего варианта использования. Поэтому почти стыдно спрашивать ... вот так.

Справочная информация: я использую IDE PhpStorm для выполнения большинства операций git. В основе PhpStorm лежит git для выполнения реальных операций.

Проблема, с которой я сталкиваюсь, заключается в том, что в PhpStorm у меня есть вспомогательный скрипт, который вставляет / обновляет комментарии PhpDo c в существующие файлы. Этот сценарий использует LF в качестве окончания строки (не настраивается), а моя IDE по умолчанию использует CRLF, потому что я на Windows. Я знаю, что мог бы установить в своей среде IDE использование LF и преобразовать весь проект в LF. Но это похоже на последнее средство.

Так что после того, как скрипт обновил PhpDo c и заменил CRLF на LF, эти файлы отображаются при запуске git status, и я не хочу этого. Git следует игнорировать файлы, которые (частично) имеют разные окончания строк. Причина, по которой я хочу git status игнорировать это, заключается в том, что PhpStorm, похоже, полагается на это для обнаружения измененных файлов и проверки этих файлов по умолчанию для фиксации. Это очень много времени, чтобы вручную go просмотреть эти файлы один за другим, чтобы PhpStorm сказал мне, что «Эти файлы идентичны» (за исключением окончаний строк)

Я пробовал это руководство , пробовал всевозможные варианты с настройкой core.autocrlf, и я попробовал десятки решений для SO, но я все еще не нашел решение.

Попытка всех этих решений научила меня нескольким вещам о git, поэтому, если вы понимаете git, настройка core.autocrlf=true не имеет значения в этом случае, потому что это преобразовывает CRLF в LF при фиксации, но моя цель - исключить их из git status. Я играл с git diff --ignore-cr-at-eol, и это больше не показывает различия, но статус git все еще показывает.

Ответы [ 2 ]

2 голосов
/ 17 апреля 2020

Извините, что говорю вам, но то, что вы хотите, чтобы git делал, противоречит тому, что такое git и как оно работает. Git считает любое изменение на уровне байтов изменением, и вы не можете отменить это. Это не имеет смысла. git diff позволяет вам сделать это только для удобства , чтобы при просмотре различий можно было сосредоточиться на соответствующих изменениях (например, так же, как многие инструменты различий имеют настройки, игнорирующие изменения пробелов).

Я использую Webstorm, и он поддерживает .editorconfig, который сам поддерживает разные конфигурации для разных файлов. У меня нет времени, чтобы проверить, будет ли поддержка JetBrain .editorconfig соответствовать настройкам каждого файла, но это может быть вашим лучшим вариантом.

другие альтернативы

  • написать сценарий, который удаляет CR из сценария. Вы можете настроить git hook для автоматического запуска при коммите. Как только вы это сделаете, я считаю, что в IDE JetBrains появится флажок в диалоге фиксации .

  • сообщают о проблеме с JetBrains, поскольку я знаю, что многие редакторы имеют опцию «автоопределение концов строк для существующих файлов».

1 голос
/ 17 апреля 2020

Я знаю, что могу настроить свою среду IDE на использование LF и преобразовать весь проект в LF. Но это похоже на крайнее решение.

Это действительно лучшее решение. Причина в том, что, как вы указываете, каждый раз, когда вам приходится иметь дело с этим, вы должны перепроверять документацию и внимательно ее читать. Существует core.autocrlf и core.eol, а затем .gitattributes на файл. И я думаю, что даже при всей этой гибкости могут быть случаи использования, которые еще не охвачены. По моему мнению, работа с окончаниями строк не стоит времени.

Поэтому я всегда рекомендую сделать зачистку, чтобы очистить репо в любые концовки, которые вы предпочитаете, и покончить с этим. Если вы не можете сделать это сразу, потому что вы делитесь репо со многими людьми, установите ловушку, чтобы проверить, что новые коммиты выполнены в правильном стиле, или даже выполните очистку автоматически. Затем подождите, пока не будут выполнены все общие части, и, наконец, выполните последнюю проверку.

...