Ответ 1

Хорошо, я как бы решил проблему.

Казалось, что файл .gitattributes, содержащий:

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

файлы проекта выглядели неустановленными. Я не знаю, почему это так, и я действительно надеюсь, что кто-то, кто занимается способами git, даст нам приятное объяснение.

Мое исправление заключалось в том, чтобы удалить эти файлы и добавить autocrlf = false под [core] в .git/config.

Это не то же самое, что и предыдущая конфигурация, поскольку для каждого разработчика требуется autocrlf = false. Я бы хотел найти лучшее решение.

EDIT:

Я прокомментировал инкриминирующие строки, раскомментировал их, и это сработало. Что... я даже не...!

Ответ 2

У меня была та же проблема, и она была связана с файлом .gitattributes. Однако тип файла, вызвавший проблему, не был указан в .gitattributes.

Мне удалось решить проблему, просто запустив

git rm .gitattributes
git add -A
git reset --hard

Ответ 3

Git не будет reset файлов, которые не находятся в репозитории. Итак, вы можете:

$ git add .
$ git reset --hard

Это приведет к изменению всех изменений, которые заставят Git знать эти файлы, а затем reset их.

Если это не сработает, вы можете попытаться отменить изменения:

$ git stash
$ git stash drop

Ответ 4

РЕШЕНО!!!

Я решил эту проблему, используя следующие stpes

1) Удалите каждый файл из индекса Git.

git rm --cached -r .

2) Перепишите индекс Git, чтобы получить все новые окончания строки.

git reset --hard

Решение было частью шагов, описанных на сайте Git https://help.github.com/articles/dealing-with-line-endings/

Ответ 5

Если вы используете Git для Windows, это, вероятно, ваша проблема

У меня была та же проблема, и тайник, полный сброс, очистка или даже все они оставляли изменения позади. Проблема оказалась в том, что режим x file не был правильно установлен git. Это "известная проблема" с git для windows. Локальные изменения отображаются в gitk и git status как старый режим 100755, новый режим 100644, без каких-либо реальных различий в файлах.

Исправление состоит в том, чтобы игнорировать режим файла:

git config core.filemode false

Больше информации здесь

Ответ 6

Возможная причина № 1 - Нормализация конца строки

Одна из ситуаций, в которой это может произойти, - когда рассматриваемый файл был зарегистрирован в хранилище без правильной конфигурации для концов строк (1), в результате чего в хранилище был файл с неверными окончаниями строк или смешанными окончаниями строк. Чтобы подтвердить, убедитесь, что git diff показывает только изменения в git diff | cat -v строки (по умолчанию они могут не отображаться, попробуйте git diff | cat -v чтобы увидеть возврат каретки в виде буквенных символов ^M).

Впоследствии кто-то, вероятно, добавил .gitattributes или изменил параметр core.autocrlf чтобы нормализовать окончания строк (2). Основываясь на .gitattributes или глобальной конфигурации, Git применил локальные изменения к вашей рабочей копии, которые применяют запрошенную нормализацию конца строки. К сожалению, по какой-то причине git reset --hard не отменяет эти изменения нормализации строки.

Решение

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

Наилучший вариант - позволить git применить необходимую нормализацию путем нормализации всех концов строк в репо, чтобы они соответствовали .gitattributes, и .gitattributes этих изменений - см. Попытка исправить окончания строк с помощью git filter-branch, но без удачи

Если вы действительно хотите попытаться отменить изменения в файле вручную, то, кажется, самое простое решение - стереть измененные файлы, а затем сказать git о их восстановлении, хотя я отмечаю, что это решение не работает согласованно на 100% время (ВНИМАНИЕ: НЕ запускайте это, если ваши измененные файлы имеют изменения, отличные от окончаний строки !!):

    git status --porcelain | grep "^ M" | cut -c4- | xargs rm
    git checkout -- .

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

Возможная причина № 2 - нечувствительность к регистру

Вторая возможная причина - нечувствительность к регистру в Windows или Mac OS/X. Например, допустим, что в хранилище существует следующий путь:

/foo/bar

Теперь кто-то в Linux фиксирует файлы в /foo/Bar (возможно, из-за инструмента сборки или чего-то, что создало этот каталог) и отправляет. В Linux это теперь две отдельные директории:

/foo/bar/fileA
/foo/Bar/fileA

Проверка этого репо в Windows или Mac может привести к изменению fileA который не может быть сброшен, потому что при каждом сбросе git в Windows /foo/bar/fileA, а затем, поскольку Windows не /foo/bar/fileA регистр, перезаписывает содержимое fileA с помощью /foo/Bar/fileA, в результате чего они "модифицируются".

Другим случаем может быть отдельный файл (ы), который существует в репо, который при извлечении в нечувствительной к регистру файловой системе будет перекрываться. Например:

/foo/bar/fileA
/foo/bar/filea

Могут быть и другие подобные ситуации, которые могут вызвать такие проблемы.

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

Решение

Решение состоит в том, чтобы привести в соответствие регистр файлов в индексе git и регистр в файловой системе Windows. Это можно сделать либо в Linux, который покажет истинное положение вещей, либо в Windows с очень полезной утилитой с открытым исходным кодом Git-Unite. Git-Unite применит необходимые изменения регистра к индексу git, которые затем могут быть переданы в репо.

(1) Скорее всего, это кто-то использовал Windows, без какого- .gitattributes определения .gitattributes для рассматриваемого файла, и использовал глобальный параметр по умолчанию для core.autocrlf который имеет значение false (см. (2)).

(2) http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/

Ответ 7

Другой причиной этого может быть файловая система без учета регистра. Если в вашем репо есть несколько папок на том же уровне, имена которых отличаются только в зависимости от случая, вы получите это. Просмотрите исходный репозиторий, используя его веб-интерфейс (например, GitHub или VSTS), чтобы убедиться.

Для получения дополнительной информации: fooobar.com/questions/7485/...

Ответ 8

Запустить команду очистки:

# Remove all untracked files and directories. (`-f` is `force`, `-d` is `remove directories`)

git clean -fd

Ответ 9

Ни один из этих методов не работал у меня, единственным решением было уничтожить все репо и повторно клонировать его. Это включает в себя стирание, сброс, добавление, сброс, настройки clrf, чувствительность к регистру и т.д. Sigh..

Ответ 10

Проверьте .gitattributes.

В моем случае у меня есть *.js text eol=lf, а git опция core.autocrlf была true.

Это приводит меня к ситуации, когда git автоконвертирует окончание строк моих файлов и не позволяет мне его исправить, и даже git reset --hard HEAD ничего не сделал.

Я исправляю это с комментарием *.js text eol=lf в моем .gitattributes и раскомментировал его после него.

Похож на магию git.

Ответ 11

Вы можете stash отменить свои изменения, а затем отбросить тайник:

git stash
git stash drop

Ответ 12

Я столкнулся с аналогичной проблемой, связанной с .gitattributes, но для моего дела была задействована GitHub LFS. Хотя это не совсем сценарий OP, я думаю, что он дает возможность проиллюстрировать, что делает файл .gitattributes, и почему он может привести к неустановленным изменениям в виде различий "phantom".

В моем случае файл уже был в моем репозитории, например, с самого начала. В недавнем коммите я добавил новое правило git-lfs track, используя шаблон, который был в ретроспективе слишком широк и в конечном итоге соответствовал этому древнему файлу. Я знаю, что не хочу менять этот файл; Я знаю, что я не менял файл, но теперь это было в моих неустановленных изменениях, и никакие проверки или жесткие сбрасывания в этом файле не собирались его исправлять. Почему?

Расширение LFS GitHub работает в основном за счет использования крючков, которые git обеспечивает доступ через файл .gitattributes. Как правило, записи в .gitattributes указывают, как должны обрабатываться файлы соответствия. В случае OP это касалось нормализации окончания строки; в моей, было ли позволить LFS обрабатывать хранилище файлов. В любом случае фактический файл, который git видит при вычислении git diff, не соответствует файлу, который вы видите при проверке файла. Следовательно, если вы измените способ обработки файла с помощью шаблона .gitattributes, который соответствует ему, он будет отображаться как неустановленные изменения в отчете о состоянии, даже если в файле действительно нет изменений.

Все, что сказал, мой "ответ" на вопрос: если изменение в файле .gitattributes - это то, что вы хотели сделать, вам следует просто добавить изменения и перейти. Если нет, то измените .gitattributes, чтобы лучше представить, что вы хотите делать.

Ссылки

• Спецификация GitHub LFS - Отличное описание того, как они подключаются к вызовам функций clean и smudge, чтобы заменить ваши файл в объектах git с простым текстовым файлом с хешем.

• gitattributes Документация - Все подробности о том, что доступно для настройки процесса обработки git ваших документов.

Ответ 13

Если другие ответы не работают, попробуйте добавить файлы, а затем сбросить

$ git add -A
$ git reset --hard

В моем случае это помогло, когда была куча пустых файлов, которые отслеживал git.

Ответ 14

У меня была та же проблема. Я сделал git reset --hard HEAD, но все же каждый раз, когда я делал git status, я видел некоторые файлы как измененные.

Мое решение было относительно простым. Я только что закрыл IDE (вот он был Xcode) и закрыл мою командную строку (здесь он был терминальным на моей Mac OS) и попробовал еще раз, и это сработало.

Тем не менее я никогда не мог найти причину проблемы.

Ответ 15

Я считаю, что существует проблема с git для Windows, где git случайным образом записывает неправильные окончания строки при проверке, и единственным обходным решением является проверка другой ветки и принудительное использование git для игнорирования изменений. Затем проверьте ветку, на которой вы на самом деле хотите работать.

git checkout master -f
git checkout <your branch>

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

Изменить: мне, возможно, повезло в первый раз. Оказывается, я снова начал битку после переключения ветвей. Оказалось, что файлы git сообщали как измененные после смены ветвей. (По-видимому, поскольку git не применял последовательно линию CRLF, заканчивающуюся до файлов.)

Я обновил до последней версии git для Windows и надеюсь, что проблема ушла.

Ответ 16

Аналогичная проблема, хотя я уверен только на поверхности. В любом случае, это может помочь кому-то: что я сделал (FWIW, в SourceTree): спрятал незафиксированный файл, затем сделал жесткий reset.

Ответ 17

Как указывали другие ответы, проблема связана с автокоррекцией линии. Я столкнулся с этой проблемой с файлами *.svg. Я использовал svg файл для значков в моем проекте.

Чтобы решить эту проблему, я даю git знать, что файлы svg следует рассматривать как двоичные вместо текста, добавив ниже строку в .gitattributes

*. svg binary

Ответ 18

В похожей ситуации. В результате многолетних мучений со многими программистами, которые смогли объединить разные кодировки концов строк (.asp,.js,.css... не суть) в один файл. Некоторое время назад отказался.gitattributes. Настройки для репо оставлены autorclf = true и safecrlf = warn.

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

The line will have its original line endings in your working directory. warning: LF will be replaced by CRLF in...

Советы от Как нормализовать рабочие окончания линий деревьев в Git? помог

git add -u

Ответ 19

Еще одна возможность, с которой я столкнулся, заключалась в том, что один из пакетов в репозитории заканчивался отдельным заголовком. Если ни один из ответов здесь не помогает, и вы сталкиваетесь с таким сообщением о состоянии git, у вас может быть та же проблема:

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:   path/to/package (new commits)

Переходя в папку path/to/package состояние git status должно давать следующий результат:

HEAD detached at 7515f05

И следующая команда должна исправить проблему, когда master должен быть заменен вашей локальной веткой:

git checkout master

И вы получите сообщение о том, что ваша локальная ветвь будет иметь некоторое количество коммитов за удаленной веткой. git pull и ты должен быть вне леса!