Git статус показывает модификации даже с autocrlf = false

У меня возникают те же проблемы, что и в этом вопросе: git статус показывает изменения, git checkout - <file> не удаляет их

git продолжает показывать изменения рабочего каталога даже с git config --global core.autocrlf false:

E:\_dev\github\Core [master +0 ~93 -0]> git config --get-all core.autocrlf
false
false

(Обратите внимание, что я даже установил --system значение false)

Почему появляется, что git все еще меняет конец конца строки?

Попытки избавиться от модификаций

Baseline

E:\_dev\github\Core [master +0 ~93 -0]> git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   tools/StatLight/StatLight.EULA.txt
... more changes ...
no changes added to commit (use "git add" and/or "git commit -a")

git checkout -.

E:\_dev\github\Core [master +0 ~93 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~93 -0]> git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed) 
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   tools/StatLight/StatLight.EULA.txt
... more changes ...
no changes added to commit (use "git add" and/or "git commit -a")

Иногда это будет иметь эффект нечетным образом:

E:\_dev\github\Core [master +0 ~628 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~361 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~93 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~93 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~93 -0]> git checkout -- .

git reset --hard

E:\_dev\github\Core [master +0 ~93 -0]> git reset --hard
HEAD is now at 11a7f9a Merge pull request #8 from RemiBou/master
E:\_dev\github\Core [master +0 ~93 -0]>

git add.; git stash; git падение забрасывания

E:\_dev\github\Core [master +0 ~93 -0]> git add .
... warnings ....
warning: CRLF will be replaced by LF in tools/StatLight/StatLight.EULA.txt.
The file will have its original line endings in your working directory.

E:\_dev\github\Core [master +0 ~93 -0]> git stash
Saved working directory and index state WIP on master: 11a7f9a Merge pull request #8 from 
RemiBou/master
HEAD is now at 11a7f9a Merge pull request #8 from RemiBou/master

E:\_dev\github\Core [master +0 ~93 -0]> git stash drop
Dropped refs/[email protected]{0} (de4c3c863dbad789aeaf563b4826b3aa41bf11b7)

E:\_dev\github\Core [master +0 ~93 -0]> git status .\tools\StatLight\StatLight.EULA.txt
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   tools/StatLight/StatLight.EULA.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

Ответы

Ответ 1

Это похоже на ошибку в msysgit. В качестве обходного пути попробуйте создать файл . Gitattributes, содержащий

* -text

Это сообщит git не выполнять преобразования EOL для любых файлов.

Ответ 2

Проверьте, нет ли файла .gitattributes

Как упоминалось в разделе "Эффект" страницы руководства gitattributes, эти файлы также могут влиять на eol и автоматически преобразование:

text ^^^^^^

Этот атрибут включает и контролирует нормализацию конца строки.
Когда текстовый файл нормализуется, его окончания строки преобразуются в LF в репозитории.
Чтобы определить, какой стиль окончания строки используется в рабочем каталоге, используйте атрибут eol для одного файла и переменную конфигурации core.eol для всех текстовых файлов.

Проверьте также свою конфигурацию для core.eol, как указано в разделе Как конверсии завершения строк работают с git core.autocrlf между различными операционными системами.

Ответ 3

Я изучаю странное поведение core.autocrlf в MSysGit, и я обнаружил, что имея:

[core]
    autocrlf = false
    safecrlf = true
    ignorecase = true
    eol = native

в глобальном файле конфигурации и отсутствии значения core.autocrlf в репо, скопированном с другого ПК (не клонировано, только копировано), выдача команды git status приводит к появлению ВСЕХ текстовых файлов, помеченных как измененных (без gitattributes вокруг).

Но если вы добавите локальный (репозиторий) параметр core.autocrlf в значение true, а затем выполните команду git status, все изменения исчезнут, и репозиторий станет чистым.

НО (и это странное поведение), если вы удалите только что добавленный параметр core.autocrlf из файла конфигурации репозитория (таким образом, вернувшись в точное начальное состояние), команда состояния git продолжает сообщать об отсутствии изменения

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

Если это не ошибка, я не могу себе представить, кто в мире может назвать это "нормальным" поведением.

Ответ 4

Эта проблема может быть вызвана текстовым вариантом gitattributes.

Пожалуйста, внимательно прочитайте документацию, но в основном autocrlf имеет значение только если text не установлен в .gitattributes:

Не выбрано
Если текстовый атрибут не указан, git использует конфигурационную переменную core.autocrlf, чтобы определить, должен ли файл быть преобразован.

Найдите файл .gitattributes через:

find <root-dir> -name .gitattributes

И grep для text, eol или crlf, чтобы найти своего виновника и при необходимости изменить его.

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

Ответ 5

Проблема "autocrlf" является типичной проблемой для межплатформенного репозитория cross (т.е. использования доли samba с черепаховой оболочкой над сервером под Linux)

Я понял, что иногда (часто) это скорее проблема "chmod", чем автокрест: - окна состояния git отображаются в ожидании изменений - git статус linux не отображает ничего

"100755 = > 100644 config/packager.xml"

Убедитесь, что ваши "статические" файлы не являются + x, (и в этом случае черепаха не понравится)

Ответ 6

Хотя я не знаю, что вызывает это странное поведение, я знаю еще один способ отказаться от изменений, которые могут сработать.

Предупреждение! Будьте предельно осторожны и сначала сделайте резервную копию; это может быть очень разрушительным.

Если все данные, которые вам интересны, зафиксированы в репозитории, вы можете просто удалить все в своем рабочем каталоге (конечно, за исключением скрытого каталога .git) и запустить git reset --hard HEAD, чтобы git воссоздать рабочий каталог исключительно из данные репозитория.

Не забудьте внимательно проверить, нет ли у вас каких-либо важных данных, которые не отслеживаются с помощью git, прежде чем делать это. Недостаточно проверить git status на незафиксированные изменения - помните, что удаление всех файлов из рабочего каталога также удалит файлы, которые вы сказали git, чтобы игнорировать, и они не будут воссозданы с помощью git reset --hard HEAD, потому что они не отслеживается вообще.