Неустановленные изменения, оставшиеся после сброса git --hard
Название говорит само за себя.
После git reset --hard, git status дает мне файлы в Changes not staged for commit: раздел.
Я также пытался git reset ., git checkout -- . а также git checkout-index -f -a, но безрезультатно.
Итак, как я могу избавиться от этих неустановленных изменений?
Кажется, это касается только файлов проекта Visual Studio. Weird. Смотрите эту пасту: http://pastebin.com/eFZwPn9Z. Что особенного в этих файлах, это то, что в.gitattributes у меня есть:
*.sln eol=crlf
*.vcproj eol=crlf
*.vcxproj* eol=crlf
Также, autocrlf установлен в false в моем глобальном .gitconfig, Может ли это быть как-то актуально?
22 ответа
Хорошо, я вроде решил проблему.
Казалось, что .gitattributes файл, содержащий:
*.sln eol=crlf
*.vcproj eol=crlf
*.vcxproj* eol=crlf
заставил файлы проекта казаться неустановленными. Я не знаю, почему это так, и я очень надеюсь, что кто-то, знакомый со способами мерзавца, даст нам хорошее объяснение.
Мое исправление состояло в том, чтобы удалить эти файлы и добавить autocrlf = false под [core] в .git/config,
Это не то же самое, что и предыдущая конфигурация, так как требуется, чтобы каждый разработчик имел autocrlf = false, Я хотел бы найти лучшее решение.
РЕДАКТИРОВАТЬ:
Я прокомментировал компрометирующие строки, раскомментировал их, и это сработало. Что... Я даже не...!
У меня была такая же проблема, и это было связано с .gitattributes файл. Однако тип файла, вызвавший проблему, не был указан в .gitattributes,
Я смог решить проблему, просто запустив
git rm .gitattributes
git add -A
git reset --hard
ПОСТАНОВИЛИ!!!
Я решил эту проблему, используя следующие stpes
1) Удалить каждый файл из индекса Git.
git rm --cached -r .
2) Перепишите индекс Git, чтобы подобрать все новые окончания строки.
git reset --hard
Решение было частью шагов, описанных на сайте git https://help.github.com/articles/dealing-with-line-endings/
Git не будет сбрасывать файлы, которых нет в хранилище. Так что вы можете:
$ git add .
$ git reset --hard
Это внесет все изменения, которые заставят Git узнать об этих файлах, а затем сбросить их.
Если это не сработает, вы можете попытаться сохранить ваши изменения:
$ git stash
$ git stash drop
Если вы используете Git для Windows, это, вероятно, ваша проблема
У меня была та же проблема, и тайник, полный сброс, очистка или даже все они оставляли изменения позади. Проблема оказалась в том, что режим x file не был правильно установлен git. Это "известная проблема" с git для windows. Локальные изменения отображаются в gitk и git status как старый режим 100755, новый режим 100644, без каких-либо реальных различий в файлах.
Исправление состоит в том, чтобы игнорировать режим файла:
git config core.filemode false
Возможная причина № 1 - Нормализация конца строки
Одна из ситуаций, в которой это может произойти, - когда рассматриваемый файл был зарегистрирован в хранилище без правильной конфигурации для концов строк (1), в результате чего в хранилище был файл с неправильными окончаниями строк или смешанными окончаниями строк. Чтобы подтвердить, убедитесь, что git diff показывает только изменения в окончаниях строк (по умолчанию они могут быть не видны, попробуйте git diff | cat -v видеть возврат каретки как буквальный ^M персонажи).
Впоследствии кто-то, вероятно, добавил .gitattributes или изменил core.autocrlf настройка для нормализации концов строк (2). На основе .gitattributes или глобальная конфигурация, Git применил локальные изменения к вашей рабочей копии, которые применяют запрошенную нормализацию конца строки. К сожалению по какой то причине git reset --hard не отменяет эти изменения нормализации строки.
Решение
Обходные пути, в которых обнуляются локальные окончания строк, не решат проблему. Каждый раз, когда git "видит" файл, он пытается применить нормализацию, что приводит к той же проблеме.
Лучший вариант - позволить git применить нормализацию, которую он хочет, нормализуя все окончания строк в репо, чтобы соответствовать .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 не учитывает регистр, перезаписывает содержимое 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 определение для рассматриваемого файла, и с использованием глобальной настройки по умолчанию для core.autocrlf который false (см. (2)).
(2) http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/
Если другие ответы не работают, попробуйте добавить файлы, а затем сбросить
$ git add -A
$ git reset --hard
В моем случае это помогло, когда была куча пустых файлов, которые отслеживал git.
Другой причиной этого могут быть файловые системы без учета регистра. Если у вас есть несколько папок в вашем репо на одном уровне, имена которых отличаются только регистром, вы будете поражены этим. Просмотрите исходный репозиторий, используя его веб-интерфейс (например, GitHub или VSTS), чтобы убедиться.
Для получения дополнительной информации: /questions/24108656/git-status-pokazyivaet-izmeneniya-git-checkout-file-ne-udalyaet-ih/24108693#24108693
Вы можете stash удалите свои изменения, затем бросьте тайник:
git stash
git stash drop
Запустите чистую команду:
# Remove all untracked files and directories. (`-f` is `force`, `-d` is `remove directories`)
git clean -fd
Я полагаю, что существует проблема с git для Windows, где git случайным образом записывает неправильные окончания строк при оформлении заказа, и единственным обходным решением является извлечение какой-либо другой ветви и принудительное игнорирование изменений в git. Затем проверьте ветку, над которой вы действительно хотите работать.
git checkout master -f
git checkout <your branch>
Имейте в виду, что при этом будут отменены любые изменения, которые вы могли умышленно внести, поэтому делайте это только в том случае, если у вас возникла эта проблема сразу после оформления заказа.
Изменить: я мог бы действительно повезло в первый раз. Оказывается, я снова получил немного после переключения веток. Оказалось, что файлы, о которых git сообщает, были изменены после изменения веток. (Очевидно, потому что git не всегда правильно применял конец файла CRLF к файлам.)
Я обновился до последней версии Git для Windows и надеюсь, что проблема исчезла.
Ни один из этих методов не работал для меня, единственное решение состояло в том, чтобы уничтожить весь репо и повторно клонировать его. Это включает в себя сохранение, сброс, добавление, сброс, настройки clrf, чувствительность к регистру и т. Д. Вздох..
Проверьте свои .gitattributes,
В моем случае у меня есть *.js text eol=lf в нем и мерзкий вариант core.autocrlf было true,
Это приводит меня к ситуации, когда git автоматически конвертирует окончания строк моих файлов и мешает мне это исправить и даже git reset --hard HEAD ничего не делал
Я исправляю это комментированием *.js text eol=lf в моем .gitattributes и оставил комментарий после него.
Похоже, это просто волшебство.
Попробуйте просто git restore .
Это то, что говорит git, и он работает
У меня такая же проблема. я сделал git reset --hard HEAD но все равно каждый раз, когда я делал git status Я видел некоторые файлы как измененные.
Мое решение было относительно простым. Я просто закрыл свою IDE (здесь это был Xcode) и закрыл командную строку (здесь это был терминал на моей Mac OS) и попробовал снова, и это сработало.
И все же я так и не смог найти причину проблемы.
Я столкнулся с аналогичной проблемой, также связанной с .gitattributes, но для моего случая задействован LFS GitHub. Хотя это не совсем сценарий ОП, я думаю, что он дает возможность проиллюстрировать, что .gitattributes Файл делает и почему это может привести к неустановленным изменениям в виде "фантомных" различий.
В моем случае файл уже был в моем хранилище, как с начала времен. В недавнем коммите я добавил новый git-lfs track Правило, используя шаблон, который был задним числом слишком широким, и заканчивая тем, что соответствовал этому древнему файлу. Я знаю, что не хотел менять этот файл; Я знаю, что не менял файл, но теперь он был в моих неустановленных изменениях, и никакие проверки или повторные сбросы в этом файле не собирались его исправлять. Зачем?
Расширение GitHub LFS работает в основном за счет использования хуков, которые git обеспечивает доступ через .gitattributes файл. Как правило, записи в .gitattributes указать, как должны обрабатываться соответствующие файлы. В случае OP это было связано с нормализацией концов строк; по моему, было ли позволить LFS обрабатывать хранилище файлов. В любом случае, на самом деле файл, который git видит при вычислении git diff не соответствует файлу, который вы видите при проверке файла. Следовательно, если вы измените способ обработки файла с помощью .gitattributes соответствующий шаблону, он будет отображаться как неустановленные изменения в отчете о состоянии, даже если в файле действительно нет изменений.
Все, что сказал, мой "ответ" на вопрос, что если изменение в .gitattributes Файл - это то, что вы хотели сделать, вы должны просто добавить изменения и двигаться дальше. Если нет, то исправьте .gitattributes чтобы лучше представлять, что вы хотите делать.
Рекомендации
GitHub LFS Specification - отличное описание того, как они подключаются к
cleanа такжеsmudgeвызовы функций, чтобы заменить ваш файл вgitобъекты с простым текстовым файлом с хешем.gitattributes Documentation - Вся информация о том, что доступно для настройки, как
gitобрабатывает ваши документы.
Аналогичная проблема, хотя я уверен, только на поверхности. В любом случае, это может кому-то помочь: что я сделал (FWIW, в SourceTree): спрятал незафиксированный файл, затем сделал полный сброс.
Еще одна возможность, с которой я столкнулся, заключалась в том, что один из пакетов в репозитории заканчивался отдельным заголовком. Если ни один из ответов здесь не помогает, и вы сталкиваетесь с таким сообщением о состоянии 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 и ты должен быть вне леса!
Enviro: Visual Studio 2019 + git + Azure DevOps.
Поведение
Столкнулся с этой ситуацией после попытки жесткого сброса, но у меня не из-за окончания строки.
git зависал при выполнении ряда команд; другими словами, он никогда не вернется в командную строку. Он покажет файлы в данной команде как обработанные, но не завершит все «этапы» команды.
git clone, например:
Решение
Создайте новый токен личного доступа PAT
Была ли проблема с безопасностью/учетными данными, связанная с моим существующим PAT, но я не смог найти никаких журналов, свидетельствующих о том, что он не работает.
В похожей ситуации. В результате многолетних мучений со многими программистами, которые сумели собрать разные кодировки концов строк (.sp, .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
Как указывалось в других ответах, проблема заключается в автокоррекции конца строки. Я столкнулся с этой проблемой с *.svg файлами. Я использовал SVG-файл для иконок в моем проекте.
Чтобы решить эту проблему, я позволил git знать, что файлы svg следует рассматривать как двоичные, а не текстовые, добавив следующую строку в.gitattributes
*.svg бинарный
По какой-то причине
git add .
не сработало, но
$ git add -A
сработало!