статус git показывает изменения даже при autocrlf=false

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

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

E:_devgithubCore [master +0 ~93 -0]> git config --get-all core.autocrlf
false
false

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

почему кажется, что Git все еще изменяет мой конец строк?

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

базовый

E:_devgithubCore [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:_devgithubCore [master +0 ~93 -0]> git checkout -- .
E:_devgithubCore [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:_devgithubCore [master +0 ~628 -0]> git checkout -- .
E:_devgithubCore [master +0 ~361 -0]> git checkout -- .
E:_devgithubCore [master +0 ~93 -0]> git checkout -- .
E:_devgithubCore [master +0 ~93 -0]> git checkout -- .
E:_devgithubCore [master +0 ~93 -0]> git checkout -- .

git reset --hard

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

git добавить .; git stash; git stash drop

E:_devgithubCore [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:_devgithubCore [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:_devgithubCore [master +0 ~93 -0]> git stash drop
Dropped refs/stash@{0} (de4c3c863dbad789aeaf563b4826b3aa41bf11b7)

E:_devgithubCore [master +0 ~93 -0]> git status .toolsStatLightStatLight.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")
33
core.autocrlf git git-status revert

6 ответов

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

* -text

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

16

проверьте, если у вас нет

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

text ^^^^^^

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

проверьте свой config для core.eol, как указано в "как преобразование окончания строки работает с git core.autocrlf между различными операционными системами".

9

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

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

в глобальном конфигурационном файле и NO ядра. настройка в репо скопирована с другого ПК (не клонирована, только скопирована), выдача git status команда приводит ко всем текстовым файлам, помеченным как измененные (нет gitattributes вокруг).

но если вы добавите локальный (репозиторий)ядра. значение true, а затем выдает , все изменения исчезают, и репозиторий снова становится чистым.

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

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

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

6

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

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

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

найти через:

find <root-dir> -name .gitattributes

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

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

5

проблема"autocrlf" является типичной проблемой для крест Multi platform repo (т. е. использование Samba share с tortoisegit над сервером под linux)

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

" изменение режима 100755 = > 100644 config / packager.XML-код"

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

1

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

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

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

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

0