Здається, не можна скасувати зміни в 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, він виглядає точно так само. Очевидно, каси не працюють. Чи я щось роблю не так? Я використовую 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для інтеграції з підривною роботою, тоді переконайтеся, що autocrlfвимкнено. Як я можу сказати, він просто порушений у цій конфігурації, і це робить більшість інструментів думкою, що файли були змінені, коли ви зробили, checkoutщоб відновити будь-які зміни.

Якщо ви бачите проблему там, де ви робите git checkout, а потім git statusпоказує, що файл все ще змінюється, і git diffпоказує, що файл змінюється в кожному рядку файлу, то це проблема, яку ви бачите.

core.autocrlf

Якщо це правда, змушує git конвертувати CRLF в кінці рядків текстових файлів у LF під час читання з файлової системи та перетворювати у зворотному порядку під час запису до файлової системи. Змінна може бути встановлена ​​на вхід, і в цьому випадку перетворення відбувається лише під час читання з файлової системи, але файли виписуються з LF в кінці рядків. Наразі, які шляхи вважати "текстом" (тобто піддаватися механізму автокреслення) вирішується виключно на основі вмісту.

core.safecrlf

Якщо це правда, робить перевірку git, якщо перетворення CRLF як кероване core.autocrlf є оборотним. Git перевірить, чи команда змінює файл у дереві робіт прямо чи опосередковано. Наприклад, створення файлу з подальшим перевіркою того самого файлу повинно отримати вихідний файл у робочому дереві. Якщо це не стосується поточного налаштування core.autocrlf, git відхилить файл. Змінна може бути встановлена ​​на "попередження", і в цьому випадку git попередить лише про необоротне перетворення, але продовжить операцію. ...

Я думаю, вам потрібно пройти -f

На головній сторінці ( man git-checkout, GIT-CHECKOUT (1)):

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

Наприклад, скасувати зміни в поточній гілці та перейти на іншу гілку:

git checkout -f master

Це може бути закінчення рядків, як підказує @ 1800-інформація, але інша можливість полягає в тому, що різниця (це заважає повернути ці файли командою оформлення замовлення) - це режим файлу. Це зі мною сталося. У моїй версії git ви можете відкрити це за допомогою

git diff index.htm

І він покаже вам зміни режиму файлу. Це все одно не дозволить вам відновити їх, хоча, використовуючи замовлення, навіть із опцією -f. Для цього використовуйте будь-який

git config core.filemode false

або змінити git .config у текстовому редакторі, додавши

[ядро]

filemode = false

Після цього ви можете використовувати

git скидання HEAD index.htm

і файл повинен зникнути.

(Я все це отримав з відповідей на те, як зробити зміни git ignored зміни (chmod)? Та оновлення-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 за замовчуванням, але Windows, мабуть, поводиться однаково), і файл був присутній як з великого, так і з малого регістру в одному каталозі, з різним вмістом. Оскільки на моєму комп’ютері обидва імені вказували на один і той же файл, статус git завжди показував модифікацію, що б я не робив. Щоб вирішити проблему:

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

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

• робити клони Git з нуля

У мене була подібна проблема, коли вона не дозволила б мені відкинути файли, які або не існують, або були змінені. Я використовую 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. Це було у відстороненому стані 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

АБО ви, ймовірно, можете додати більш локальний фільтр через a .gitconfigу корені репо і якось перезаписати там правила фільтра для lfs.

Сподіваюсь, це допоможе хлопцеві вийти.

Я також зіткнувся з дещо подібною проблемою, і наступні кроки мені допомогли:

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

Сподіваюся, що це допомагає і іншим людям.