Невозможно отказаться от изменений в Git

Ответ 1

Это беспокоило меня какое-то время, почти все репо, которые я проверил, имели изменения, которые я не мог отбросить. Короче говоря, я пробовал все вышеперечисленное, ничего не получилось. Это то, что я сделал, чтобы вернуть нормальное состояние (на Mac):

Completely remove the autocrlf & safecrlf settings from ~/.gitconfig
Completely remove the autocrlf & safecrlf settings from your repo local config ./.git/config
git rm --cached -r .
git reset --hard

Ответ 2

Какие изменения показывает git diff в файле? В Windows я видел проблемы с окончаниями строк, вызывающие такие проблемы. В этом случае посмотрите, какие настройки у вас есть для git config core.autocrlf и git config core.safecrlf. Здесь есть некоторая документация для этих настроек.

Я бы сказал, что если вы используете git svn для интеграции с Subversion, убедитесь, что autocrlf выключен. Из того, что я могу сказать, он просто поврежден в этой конфигурации, и это заставляет большинство инструментов думать, что файлы были изменены, когда вы сделали checkout чтобы отменить любые изменения.

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

core.autocrlf

Если true, заставляет git конвертировать CRLF в конце строк в текстовых файлах в LF при чтении из файловой системы и конвертировать в обратном порядке при записи в файловую систему. Переменная может быть установлена на ввод, и в этом случае преобразование происходит только во время чтения из файловой системы, но файлы записываются с LF в конце строк. В настоящее время, какие пути считать "текстом" (то есть подвергаться механизму autocrlf), определяется исключительно на основе содержимого.

core.safecrlf

Если это правда, делает git проверку, является ли обратимым преобразование CRLF, контролируемое core.autocrlf. Git проверит, изменяет ли команда файл в рабочем дереве прямо или косвенно. Например, фиксация файла с последующей проверкой того же файла должна дать исходный файл в рабочем дереве. Если это не относится к текущим настройкам core.autocrlf, git отклонит файл. Переменная может быть установлена в "warn", и в этом случае git будет только предупреждать о необратимом преобразовании, но продолжит работу....

Ответ 3

Вот мой опыт, задайте следующие переменные в .git/config:

[core]
    autocrlf = false
    safecrlf = false
    eol = crlf

затем запустите $ git checkout HEAD ., и он будет работать. но $ git checkout -- . нет, странно!

* git версия 1.9.3

Ответ 4

Думаю, вам нужно пройти -f

Из справочной страницы (man git-checkout, GIT -CHECKOUT (1)):

-f, --force
       Продолжайте, даже если индекс или рабочее дерево отличаются от HEAD.
        Используется для отбрасывания локальных изменений.

Например, отмените изменения в текущей ветке и переключитесь на другую ветку:

git checkout -f master

Ответ 5

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

git diff index.htm

И он покажет вам изменения в режиме файла. Это все равно не позволит вам вернуть их, хотя, используя checkout, даже с опцией -f. Для этого используйте либо

git config core.filemode false

или измените свой git.config в текстовом редакторе, добавив

[ядро]

filemode = false

После этого вы можете использовать

git reset HEAD index.htm

и файл должен исчезнуть.

(Я получил все это из ответов на Как мне сделать изменения режима игнорирования git (chmod)? и updating-file-permissions-only-in-git)

Ответ 6

Вы находитесь в OSX или Windows? Если это так, проблема, вероятно, состоит из двух файлов с одинаковым именем, с другим случаем. например. index.htm и Index.htm

Windows и по умолчанию OSX использует файловую систему, не учитывающую регистр, которая конфликтует с чувствительным к регистру git.

Ответ 7

У меня была эта проблема, и после того, как вы попытались все это, ничего не получилось.

Что сработало для меня, так это удалить каталог, в котором находился файл, а затем сделать git status и убедиться, что все файлы в этом каталоге теперь отмечены как удаленные. После этого я просто сделал git checkout -f, и все было в порядке.

Ответ 8

Я работал над проектом libGDX на Android Studio и я хотел отказаться от всех изменений, которые я сделал, и у меня ничего не libGDX, решение, которое я придумал, состояло в том, чтобы зафиксировать все изменения в новой ветке

git checkout -b TRASH
git add .
git commit -m "discarded changes"
git checkout master

и затем вы можете удалить ветку TRASH если хотите.

Ответ 9

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

git checkout и попытка сброса не помогла. Это не сработает, или просто скажет мне, что у меня нет разрешения.

Решение, которое сработало:

• Перейдите в безопасный режим
• Отменить файлы

Перезапуск - это боль, но это работало быстрее, чем опробовать 100 вещей.

Ответ 10

Существует простое решение. Если это происходит (как правило, из-за неожиданного закрытия окна или дампа памяти), и вы не можете отказаться от своих изменений и даже переключаться между ветвями (Git говорит, что у вас недостаточно прав); в Windows окружении show all hidden files and folders из опций папки. Перейдите в каталог GIT (следует начинать с .git) и удалять файл "index.lock". Затем GIT должен делать то, что вы хотите сделать.

Ответ 11

В итоге я сделал git stash, а затем git stash clean, чтобы избавиться от некоторых. Не видел никаких конфигураций auto cr/lf в файлах .git/или ~/.git.

Ответ 12

В моем случае я не мог отказаться от изменений, связанных с каталогом. например когда я запускал git diff, я видел бы это: -Subproject commit fdcccccccccccccccccccccccccccccccccccccc +Subproject commit f1bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

Итак, я назвал этот каталог и запустил там статус git. Это было в отключенном состоянии HEAD. И тогда я просто провел там git checkout master. Это правильно для меня. Но это не полезно для конкретного сценария, заданного здесь.

Ответ 13

Я также столкнулся с несколько схожей проблемой, и следующие шаги помогли мне:

git commit -am 'temp commit'
git pull origin master
git reset head~1
git reset head --hard

Надеюсь, это поможет и другим людям.

Ответ 14

Это старый вопрос, но он все еще имеет отношение ко мне. Я не нашел своего ответа, пока не спросил в офисе, и обнаружил, что проблема связана с подмодулями. Когда они обновляются, а ваш собственный репозиторий не отражает эти изменения, он обнаруживает, что имеет отличия, переименование главы не помогает. Если это так, запустите:

git status update

Это должно помочь исправить ситуацию (в данном конкретном случае)

Ответ 15

У меня была проблема с разрешениями в Windows, и я должен был сделать icacls containingFolder/reset/t/l/c а затем дважды щелкнуть папку, чтобы вернуть мои разрешения.

Ответ 16

У меня была такая же проблема, ничего из вышеприведенных комментариев не сработало. Оказалось, что моя файловая система не чувствительна к регистру (osx по умолчанию, но окна, вероятно, ведут себя одинаково), и в одном каталоге присутствовал файл с прописными и строчными буквами, с разным содержимым. Поскольку на моем компьютере оба имени указывали на один и тот же файл, состояние git всегда показывало изменения, независимо от того, что я делал. Чтобы решить проблему:

• Мне пришлось удалить один из файлов с другого компьютера и нажать его, чтобы сделать репо

• полностью удалить локальную версию

• делать мерзкий клон с нуля