Не могу отменить изменения в Git

Увидев в командной строке следующее:

# On branch RB_3.0.10
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   index.htm

Я пытаюсь отменить свои изменения, набрав команду:

git checkout -- index.htm

но когда я повторно запускаю git status, он выглядит точно так же. Касса не работает. Я делаю что-то неправильно? Я использую GIT 1.6.1.2 для windows / cygwin.

# On branch RB_3.0.10
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   index.htm

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

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

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

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

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

* git версии 1.9.3

Какие изменения 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

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

Я думаю тебе нужно пройти -f

На странице руководства ( man git-checkout, GIT-CHECKOUT (1)):

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

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

git checkout -f master

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

git diff index.htm

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

git config core.filemode false

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

[Ядро]

filemode = false

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

git сбросить HEAD index.htm

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

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

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

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

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

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

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

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

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

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

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

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

• сделать git clone с нуля

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

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

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

1. Перейти в безопасный режим
2. Удалить файлы

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

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

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

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

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

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

git status update

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

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

У меня были .gitattributes со следующим содержанием:

* text=auto eol=lf

Чтобы решить эту проблему, отредактируйте, .gitattributesчтобы удалить эту строку, которая ослабляет окончание строки. Затем git reset --hard HEADвернул файлы и .gitattributesфайл.

Для меня эта проблема возникла из-за комбинации загрузки образа Git-LFS, который был загружен через Netlify CMS и по-разному обслуживается их обработчиком Netlify Large Media.

Мое решение заключалось в том, чтобы закомментировать / удалить эти строки из моего ~/.gitconfig чтобы они выглядели так, как показано ниже, а затем git statusснова проверить .

# [filter "lfs"]
#   clean = git-lfs clean %f
#   smudge = git-lfs smudge %f
#   required = true

ИЛИ вы, вероятно, можете добавить более локальный фильтр через .gitconfig в корне репо и каким-то образом перезаписать там правила фильтрации для lfs.

Надеюсь, это поможет парню.

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

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

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