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

Question

ローカルで変更したと思われる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ました。

Answer 1

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

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

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

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

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

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

-アル

Answer 2

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

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

Answer 3

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

* text=auto

に：

#* text=auto

ヒントを提供してくれた@SimonEastに感謝し、保存して閉じてから、元に戻すかリセットします

Answer 4

もう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）への回答から得ましたか？）

Answer 5

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

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

Answer 6

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

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

git config --local core.autocrlf false

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

Answer 7

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

Answer 8

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

$ 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

再現する2番目の方法： 上記のスクリプトで、次の行を置き換えます。 残りの行をそのままにします
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してからコミットすることができます。

Answer 9

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

その場合を確認するには、リモートリポジトリが二重構造になっているかどうかを確認してください。

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

Answer 10

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

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

---

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

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

git rm --cached -r .

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

git reset --hard

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

Answer 11

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

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

Answer 12

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

Answer 13

私の問題は別のものでした。reset、、、、または他cleanのgitコマンドの量はrestore私の問題を解決しませんでした。また、ファイルを削除したり、元に戻したりしてみましたが、プルするたびにすぐに戻ってきました。

> git status
On branch master
Your branch is behind 'origin/master' by 319 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   bucket/stellarium.json

私はそれを次のように修正しました：

ファイルの名前を変更/邪魔にならない場所に移動します。（->ではない git mv）

> mv .\bucket\stellarium.json .\bucket\stellarium_DELETEME.json
> git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    bucket/stellarium.json

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        bucket/stellarium_DELETEME.json

ファイルを復元します。

> git restore .\bucket\stellarium.json
> git status
On branch master
Your branch is up to date with 'origin/master'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        bucket/stellarium_DELETEME.json

名前を変更したファイルを削除します。

> rm .\bucket\stellarium_DELETEME.json
> git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

それで... ？

おそらく、ディスクのFATが台無しになりましたか？わからない。まだわからない。しかし、それはうまくいきました。

Answer 14

そこに行って、時間は常に私の最大の敵の1つだったので、最も簡単な解決策を選ぶことにしました。

1. 2つのローカルバージョンファイルを別の場所に移動します
2. コミットしてプッシュ
3. ファイルを手動でgitサーバーにコピーします
4. 引く