Git：「変更されたがコミットされていない」で頑固にスタックしている2つのファイルを元に戻すにはどうすればよいですか？

ローカルで変更したと思われる2つのファイルがあるリポジトリがあります。

だから私はこれで立ち往生しています：

$ git status
# On branch master
# 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:   dir1/foo.aspx
#       modified:   dir2/foo.aspx
#
no changes added to commit (use "git add" and/or "git commit -a")

Doinggit diffは、ファイルの内容全体が変更されたと言っていますが、目で見てみると正しくないように見えます（diffでは見落とされているように見える一般的な行範囲があるようです）。

興味深いことに、これらのファイルをローカルで変更したことを覚えていません。このリポジトリは、1つのリモートリポジトリ（プライベート、GitHub.com、FWIW）で使用されます。

何を試しても、これらのローカルな変更を破棄することはできません。私はすべてを試しました：

$ git checkout -- .
$ git checkout -f
$ git checkout -- dir1/checkout_receipt.aspx
$ git reset --hard HEAD
$ git stash save --keep-index && git stash drop
$ git checkout-index -a -f

言い換えれば、Gitでステージングされていない変更を破棄するにはどうすればよいですか？で説明されているすべてを試しました。プラス以上。しかし、2つのファイルは「変更されたがコミットされていない」としてスタックしたままです。

一体何が原因で2つのファイルがこのようにスタックし、一見「テーブルを元に戻さない」のでしょうか？

PS私がすでに試したコマンドを示している上記のリストでgit revert、私が意図しgit checkoutたときに誤って書いた。申し訳ありませんが、試してみるべきだと答えてくれた皆さんに感謝しますcheckout。質問を編集して修正しました。私は間違いなくすでに試しましたcheckout。

ファイルの行末は何ですか？私は彼らがCRLFだと確信しています。もしそうなら、このガイドをチェックしてください：http：//help.github.com/line-endings/

つまり、コミット時に行末をLFに変換するようにgitが設定されていることを確認してから、それらのファイルをコミットする必要があります。gitを正しく設定していると仮定すると、リポジトリ内のファイルは常にLFであり、チェックアウトされるファイルはOSのネイティブである必要があります。

私は同様の問題を解決するために何時間も費やしました-私がチェックアウトしたリモートブランチは、すべてのファイルを削除してgit checkout -f再度実行した場合でも（またはこの投稿の他のバリエーション）、4つのファイルを「変更されましたが更新されていません」と頑固に表示しました！

これらの4つのファイルは必要でしたが、確かに私は変更していませんでした。私の最終的な解決策-変更されていないことをGitに説得します。以下は、チェックアウトされたすべてのファイルに対して機能し、「変更済み」ステータスを示します。実際に変更されたファイルをすでにコミット/スタッシュしていることを確認してください。

git ls-files -m | xargs -i git update-index --assume-unchanged "{}"

ただし、Mac OSXでは、xargsの動作は少し異なります（コメントはDaniel）。

git ls-files -m | xargs -I {} git update-index --assume-unchanged {}

次回はこれを自分のプレースホルダーとして追加しましたが、他の人にも役立つことを願っています。

-アル

これは私が私の場合に同じ問題を修正した方法です：open .gitattributes change：

* text=auto

に：

#* text=auto

ヒントをくれた@SimonEastのおかげで、保存して閉じてから、元に戻すかリセットします

もう1つの可能性は、違い（checkoutコマンドでこれらのファイルを元に戻すことができない）がファイルモードの1つであるということです。これが私に起こったことです。私のバージョンのgitでは、次を使用してこれを見つけることができます

git diff dir1 / foo.aspx

また、ファイルモードの変更が表示されます。ただし、それでも元に戻すことはできません。そのためにはどちらか

git config core.filemode false

または、テキストエディタでgit.configを追加して変更します

[芯]

filemode = false

これを行った後、あなたは使用することができます

git reset HEAD dir1 / foo.aspx

ファイルが消えるはずです。

（これはすべて、gitにモード変更を無視させる方法（chmod）への回答から得ましたか？）

ローカルの変更を元に戻してみてください：

git checkout -- dir1/foo.aspx
git checkout -- dir2/foo.aspx

変更されたものとして表示されていたが、実際には同一であるいくつかの幻の変更されたファイルがありました。

このコマンドを実行すると、機能する場合があります:(
gitの「スマート」であるが、多くの場合役に立たない行末変換をオフにします）

git config --local core.autocrlf false

しかし、別のケース.gitattributesでは、ルート内のファイルに行末設定があり、autocrlfオフになっている場合でも特定のファイルに適用しようとしていたことが原因であることがわかりました。それは実際には役に立たなかったので、削除.gitattributesしてコミットすると、ファイルが変更されたものとして表示されなくなりました。

git checkout dir1/foo.aspx
git checkout dir2/foo.aspx

また、大文字と小文字を命名するディレクトリに関連する問題が発生した可能性があります。同僚の中には、ディレクトリの名前をたとえばmyHandlerからMyHandlerに変更した可能性があります。後で元のディレクトリのファイルの一部をプッシュおよびプルした場合、リモートリポジトリには2つの個別のディレクトリがあり、ローカルマシンには1つしかありません。これは、Windowsでは1つしか持つことができないためです。そして、あなたは困っています。

その場合を確認するには、リモートリポジトリが二重構造であるかどうかを確認します。

これを修正するには、リポジトリの外部に親ディレクトリのバックアップコピーを作成してから、親ディレクトリを削除してプッシュします。プルして（削除済みとしてマークされた2番目のマークがステータスに表示される場合）、もう一度プッシュします。その後、バックアップから構造全体を再作成し、変更を再度プッシュします。

問題をよりよく理解するために、問題を再現する方法についてのヒントを提供することが役立つと思います。

$ git init
$ echo "*.txt -text" > .gitattributes
$ echo -e "hello\r\nworld" > 1.txt
$ git add 1.txt 
$ git commit -m "committed as binary"
$ echo "*.txt text" > .gitattributes
$ echo "change.." >> 1.txt

# Ok let's revert now

$ git checkout -- 1.txt
$ git status
 modified:   1.txt

# Oooops, it didn't revert!!


# hm let's diff:

$ git diff
 warning: CRLF will be replaced by LF in 1.txt.
 The file will have its original line endings in your working 
 directory.
 diff --git a/1.txt b/1.txt
 index c78c505..94954ab 100644
 --- a/1.txt
 +++ b/1.txt
 @@ -1,2 +1,2 @@
 -hello
 +hello
  world

# No actual changes. Ahh, let's change the line endings...

$ file 1.txt 
 1.txt: ASCII text, with CRLF line terminators
$ dos2unix 1.txt
 dos2unix: converting file 1.txt to Unix format ...
$ git diff
 git diff 1.txt
 diff --git a/1.txt b/1.txt
 index c78c505..94954ab 100644
 --- a/1.txt
 +++ b/1.txt
 @@ -1,2 +1,2 @@
 -hello
 +hello
  world

# No, it didn't work, file is still considered modified.

# Let's try to revert for once more:
$ git checkout -- 1.txt
$ git status
 modified:   1.txt

# Nothing. Let's use a magic command that prints wrongly committed files.

$ git grep -I --files-with-matches --perl-regexp '\r' HEAD

HEAD:1.txt

第二の方法は、再現します ：上記のスクリプトでは、この行を置き換える
echo "*.txt -text" > .gitattributes
と
git config core.autocrlf=false
、そのまま残りの行を保ちます

上記のすべてが言うこと？テキストファイルをすることができます（一部の状況下で）（例えば、CRLFでコミットすること-textで.gitattributes/またはcore.autocrlf=false）。

後で同じファイルをテキスト（-text-> text）として扱いたい場合は、再度コミットする必要があります。
もちろん、一時的に元に戻すこともできます（Abu Assarが正しく回答したとおり）。私たちの場合には：

echo "*.txt -text" > .gitattributes
git checkout -- 1.txt
echo "*.txt text" > .gitattributes

答えは次のとおりです。ファイルを変更するたびに同じ問題が発生するため、本当に実行しますか。

記録のために：

リポジトリでこの問題を引き起こす可能性のあるファイルを確認するには、次のコマンドを実行します（gitは--with-libpcreでコンパイルする必要があります）。

git grep -I --files-with-matches --perl-regexp '\r' HEAD

ファイルをコミットすることで（テキストとして扱いたい場合）、このリンクhttp://help.github.com/line-endings/で提案されている問題を修正するのと同じことです。。ただし、を削除.git/indexして実行する代わりにreset、ファイルを変更してから実行git checkout -- xyz zyfしてからコミットすることができます。

私は同じ問題を抱えていましたが、ファイルがWindowsで変更されたという興味深い追加がありましたが、WSLからファイルを見るとそうではありませんでした。行末やリセットなどをいじって変更することはできませんでした。

最終的に、私はこの答えで解決策を見つけました。以下は、便利なテキストです。

次の手順でこの問題を解決しました

1）Gitのインデックスからすべてのファイルを削除します。

git rm --cached -r .

2）Gitインデックスを書き直して、すべての新しい行末を取得します。

git reset --hard

ソリューションは、gitサイトhttps://help.github.com/articles/dealing-with-line-endings/で説明されている手順の一部でした 。

私にとって、問題は行末ではありませんでした。フォルダ名の大文字と小文字を変更することでした（Reset_password-> Reset_Password）。このソリューションは私を助けました：https： //stackoverflow.com/a/34919019/1328513

gitは大文字の違いを異なるファイルとして扱いますが、Windowsはそれらを同じファイルとして扱うため、この問題も発生する可能性があります。ファイル名の大文字と小文字が変更されているだけの場合、そのリポジトリのすべてのWindowsユーザーはこの状況になります。

解決策は、ファイルの内容が正しいことを確認してから、それを再コミットすることです。2つのファイルの内容が異なるため、それらをマージする必要がありました。次にプルすると、重複ファイルを削除することで解決できるマージの競合が発生します。マージ解決を再コミットすると、安定した状態に戻ります。