リモートブランチからリポジトリを更新しようとしていますが、「gitpull」を実行するとこのエラーが発生し続けます。ローカルでの変更は行っていません。変更したとしても、保持する必要はありません。
私はもう試した：
git reset --hard
そして私は同じ問題を抱えています
動作しているように見える唯一のことは、問題のあるファイルを削除して、gitpullを再試行することです。
私も試したgit stash後、git pull。立ち入り禁止。
編集：PortableGit-1.6.4-preview20090729を使用して、誤ったエラーを伴う以前のバグを修正する必要があります。
git rm --cached learned/tests/temp_funcs.py-とにかくファイルを未追跡ファイルリストに残したかったのでgit rm --cached、この場合はブロックを解除しました。
--abort。問題のあるファイルを削除することを除いて、提案された解決策のどれも私が中止することを許可しませんでした。
回答:
これを修正する方法はいくつかありますが、gitstashが私に適していることがわかりました。それは一時的にあなたのローカルな変更を別の場所に置きます。次に、プルして最新の変更を取得できます。そして、ローカルの変更を取り戻すことができます。
ちょうどこのような：
$ git pull
...
...
file your_file.rb not up to date, cannot merge.
$ git stash
$ git pull
$ git stash pop
git rm --cached、完全なコメント：stackoverflow.com/questions/1248029/…–
これは、特定のファイルを無視するようにインデックスを更新した場合に発生する可能性があります。
git update-index --assume-unchanged <file>
次に、たとえば他のブランチをチェックアウトします。
git checkout <branch>
> error: Entry '<file>' not uptodate. Cannot merge.
インデックスの更新を強制すると、問題が修正されます。
git update-index --really-refresh
<file>: needs update
に続く：
git reset --hard
そして、すべてが正常に戻るはずです。
git rm --cached learned/tests/temp_funcs.py-とにかくファイルを未追跡ファイルリストに残したかったのでgit rm --cached、この場合はブロックを解除しました。
git update-index --really-refresh欠けていました！よくできました、これを見つけるのは困難でした
この種の問題は、大文字と小文字のみが異なる2つのファイル名を持つリポジトリからプルしようとすることによって頻繁に発生します。FAT、大文字と小文字を区別しないモードのNTFS（基本的に、Windowsで使用されている場合）、または大文字と小文字を区別しないモードのHFS +を使用していて、2つのファイル「foobar」と「FOOBAR」がある場合、Gitには2つの異なるファイルが表示されます。ファイルが表示されますが、ファイルシステムで認識されるのは1つだけであり、あらゆる種類の問題が発生します。Gitは、たとえば「FOOBAR」をチェックアウトしてから、「foobar」をチェックアウトします。これは、ファイルシステムが「FOOBAR」の内容を単に置き換えたものと見なしますが、そのままにしておきます。Gitにとって、「FOOBAR」は「foobar」の内容に置き換えられ、「foobar」はなくなったようです。
この基本的な問題には2つの異なる兆候があります。1つは、リポジトリに実際には大文字と小文字のみが異なる2つのファイルが含まれている場合です。この場合、大文字と小文字を区別するファイルシステムで作業する必要があります。または、この種の衝突が発生しないようにリポジトリを編集する必要があります。大文字と小文字を区別しないファイルシステムでは、このリポジトリの内容を保存できません。
回避できる別のケースは、ファイルの大文字と小文字を変更する名前変更が発生した場合です。たとえば、Gitリポジトリに「EXAMPLE」から「example」への名前変更が含まれているとします。Gitは新しいバージョンをチェックアウトする前に、ディスク上にある既存のファイルを上書きしていないことを確認しようとします。「example」は新しいファイル名であると見なすため、ファイルシステムに存在するかどうかを確認し、ファイルシステムに「EXAMPLE」と表示されて「はい」と表示されるため、Gitは新しいバージョンが上書きされると判断してチェックアウトを拒否します。追跡されていないファイル。この場合、気になるローカルの変更がない場合は、単純です。git reset --hard <revision-to-checkout>通常、問題を乗り越えて新しいリビジョンに到達するには十分です。大文字と小文字を区別しないファイルシステムを使用している場合にのみ異なる名前にファイルの名前を変更しないようにしてください。このような問題が発生します。
@Brian Campbellの投稿についてさらに詳しく説明するために（ハードリセットも機能しなかったため）、私を止めていたエッジケースを指摘したいと思います。
ファイルOldFileを別のフォルダに移動して、名前を変更しましたNewFile。次に、ファイルにassume-unchanged。のフラグを付けました。
これにより、ブランチを切り替えることができず、保存したりプッシュしたりするための隠し場所がありませんでした。問題は、assume-unchangedフラグを設定する前に、このファイルの変更を新しい名前でコミットしなかったことです。だから私はそれをに戻しno-assume-unchanged、コミットし、そしてそれをに戻し、assume-unchangedそして私は再びブランチを切り替えることができた。
checkout -fても失敗します。
一般的に、これは、ローカルリポジトリにコミットされていないローカルファイルに変更があることを意味します。もう少し詳細については、このスタックオーバーフローの質問も参照してください。
私は同様の問題を見ていました（Windows 10）：私はオンになっbranchAていてに行きたいと思っていましたmaster。コミットされていない変更がいくつかあったので、最初にgit stashそれを実行しましたgit checkout -f masterが、それでもEntry 'fileName' not uptodate. Cannot merge。
git status コミットするものは何も表示されていませんでした。
最終的にはファイルを手動で削除しただけで、他のブランチに移動できたので（もちろん、ファイルが戻ってきました）、git内のどこかにバグがあったと思います。
.gitignoreファイルでエラーが発生していました！私はそれを変更していませんでしたが、gitはそれを「隠しておく」ことを許可しませんでした（ローカルな変更がないためです！）。そこで、.gitignoreファイルをリポジトリの外に（一種の「バックアップ」として）移動してからgit reset --hard、リポジトリを正常な状態に「修正」するを実行しました。
git statusどのファイルが変更されたかを示しgit restore myFile、削除する代わりに使用できることを示唆しましたが、これは機能しました。
試すだけの価値があります：
このアップデートのためだけに、configパラメーターcore.trustctimeをfalseに設定できますか？
core.trustctime
falseの場合、インデックスと作業コピーの間のctimeの違いは無視されます。iノードの変更時間がGitの外部の何か（ファイルシステムクローラーと一部のバックアップシステム）によって定期的に変更される場合に役立ちます。
git merge--abortを実行しようとしていました。コマンドgitrestore your_fileは、私にとっての問題を修正しました