web-dev-qa-db-ja.com

Gitエラー：ポインターであるはずの7つのファイルが見つかりましたが、そうではありませんでした

ステージングされたファイルが変更済みとしてマークされている場合、リポジトリをクリーンアップする方法

後

git reset --hard

私は得る

ポインターであるはずでしたが、そうではなかった7つのファイルが見つかりました。

git clean -fdx

助けにもならない

gitgit-lfs
24
Kate Zz

Git-LFSで保存されたいくつかのファイルでこの正確なエラーが発生しました リンデン誘導誘導インデックスを解決したのと同じ方法で解決しました 。

キャッシュをクリアして、ハードリセットを実行します。

git rm --cached -r .
git reset --hard

これは、リポジトリ内の巨大なgit-LFSファイルのために、新しいクローンよりも大幅に高速でした。

25
Rian Sanderson

Travis Heeterのように、彼の答えで言及されているように、次のコマンドシーケンスを試してください。

git lfs uninstall

git reset --hard

git lfs install

git lfs pull

これが機能しない場合（これが機能していないため）、次のハックが機能する可能性があります。

次のコマンドを試してください。

git rm --cached -r .

git reset --hard

git rm .gitattributes

git reset .

git checkout .

これは私のために働いた！

20
BheeMa

これは、.gitattributesで指定されているようにLFSによって追跡されるはずのファイルを含むチェックアウトを行うときに発生する可能性がありますが、代わりに直接コミットされています。ほとんどの場合、git GUIやIDEなど、リポジトリを管理する別のプログラムがあります。

これらのファイルはどこからともなく表示され、チェックアウトできないため、これはイライラする可能性があります。変更を保存するとすぐに戻ります！この状況で動けなくなった場合は、一時的なブランチでこれらの変更をコミットして、再度チェックアウトできるようにする簡単な解決策があります。

この問題を本当に修正するには、ファイルをLFSポインターとしてコミットしたことを確認してください。これは、git addを使用するのと同じくらい簡単でなければなりません。コミットする前にgit lfs statusを使用して作業を確認してください。 git lfs ls-filesは、LFSが管理しているファイルを表示します。

git lfs statusは、実際にすべての変更をリストするときにGit LFS objects to be committedを読み取るため、誤解を招きます。 LFSによって追跡されると予想されるファイルは、(LFS: c9e4f4a)ではなく、(Git: c9e4f4a -> LFS: c9e4f4a)または(Git: c9e4f4a)のようなものを読み取る必要があります。

例として、Xcode 9.2を介して画像アセットを追加するときに、これが問題であることがわかりました。ここで、自動的に追加された「CalendarChecked.png」を追加しました。

$ git status
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png

$ git lfs status

Git LFS objects to be committed:

    Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png (Git: c9e4f4a)

Git LFS objects not staged for commit:

    Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png (File: c9e4f4a)

$ git add Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png`
$ git lfs status

Git LFS objects to be committed:

    Empty/Empty/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png (LFS: c9e4f4a)

Git LFS objects not staged for commit:

$
5
slythfox

これらのソリューションはどちらもうまくいきませんでしたが、いくつかのソースをつなぎ合わせて、最終的にすべてを修正しました。

  1. 失いたくない変更をプッシュする

    メインブランチにいること、およびすべてがコミットされていることを確認してください（不良ファイルを除く）。

  2. すべてを停止

    SourceTree、任意のサーバー、ファイルエクスプローラー、ブラウザー。他の場所で使用されている場合、この機能は動作しない場合があります。疑わしいときは、やめましょう。これでやり過ぎたほうがいいです。

    このすべてを実行しても変更が適用されない場合は、コンピューターを再起動し、レポジトリに影響する可能性のあるTaskManagerのすべてを強制的に停止してから再試行してください。

  3. コマンドウィンドウ（またはターミナル）を開く

    Windowsでは、これはcmdまたはコマンドウィンドウになります。不明な場合は、windowsキーをクリックして、cmdと入力します。コマンドプロンプトが表示されるので、それをクリックします。

    cdをレポに。

  4. アンインストールlfs

    > git lfs uninstall

    次に、次のようになります。

    Hooks for this repository have been removed. Global Git LFS configuration has been removed.

  5. Reset

    > git reset --hard

    それは多くの出力を通過します...

  6. 再インストールlfs

    > git lfs install

    これは、ポインターであるべきであったがそうではなかったファイルを見つけたと再び言うかもしれません。 大丈夫、続けてください！

  7. lfsでプル

    > git lfs pull

    うまくいけば、lfsを使用してプルすると、中断されたファイルが上書きされます。

    私の情報源のいくつかは、この時点で彼らのレポが再び機能していると言ったが、個人的にはそうではない。 SourceTreeを開いて、必要かどうかを確認できますが、うまくいかなかった場合は、最初から始めなければならない場合があります。

  8. 移行

    ここでの中心的な問題は、lfsが大きなファイルをポインターに置き換えることで追跡することです。 プログラマーの場合、これは実際の値を保持するのではなく、変数がメモリ内の場所を指す方法に似ています。

    これまでに行ったことは

    • アンインストールlfs
    • すべてを削除する
    • 再インストールlfs
    • すべてを引っ張る

    これで、これらのthingsがフォルダーにfilesまたはファイルへのポインター、およびlfsは、ファイルがポインターである必要があるかどうかを把握する必要があります（逆もまた同様です）ポインタであるべきでしたが、そうではありませんでした）。 migrateを実行して、レポジトリ上のファイルを処理する手順を開始します。1Mbを超える場合、lfsはそれらをポインターに置き換えます。

    git lfs migrate

  9. その他のホラー

    ここで、他の人が停止して、彼らが再び働いていると言ったが、私ではない。エラーが発生しました：

    Git rev-listのエラー...終了ステータス128致命的：不正なリビジョン '...v1.0.0 '

    githubヘルプページ に悲劇のヒーロー@guneyozsanがいます。彼は問題を修正しなかったにもかかわらず、この最終ピースをパズルに投稿しました。この問題は2年前から存在していましたが、これを修正する方法について10億回目を探し始めた約2時間前に彼はそれを投稿しました。 @ guneyozsanを祝福し、問題を解決できることを願っています。

    > git lfs migrate info --include-ref=v1.0.0

    バージョンがエラーになったバージョンと一致することに注意してください-v1.0.0。

    このエラーが発生する理由に関するソースは見つかりませんでしたが、ローカルリポジトリのmigrateによって生成されたlfsバージョン番号がソースバージョンと一致しないと推測します。何らかの理由で、ローカルlfsデータが台無しになりました（私にとっては、プッシュ中にSourceTreeがクラッシュし、マシンを強制的に再起動したため、すべてが開始されたため、lfsデータが破損した可能性があります）対処方法を知っているので、更新しようとしているこのループでスタックしているだけですが、破損したデータを読み取ることはできません。したがって、長いトラブルシューティング。

  10. スタッシュアンドプル

    SourceTreeを開くと、おそらくすべてのファイルを元に戻したいことがわかります。それをしないでください。 Stash、次にpull。

    そしてブーム、恐怖は終わりました。うまくいけば。そうでない場合は、この gitハブページ または this one がさらに役立つ可能性がありますが、これが私にとってはうまくいきました。

3
Travis Heeter

git lfsバージョン2.5以降がインストールされていることを確認してください（ こちらからダウンロード ）。

ダウンロードしたgit lfsバージョンを使用していることを確認します（私にとっては2.7.7）：

>git lfs version
git-lfs/2.7.2

実行：

git lfs migrate import --fixup --everything

ブランチを引っ張り、マージの競合を修正します。

この中にあります github comment 。

0
Felix

次のプロセスは、lfsポインターである必要があるすべてのバイナリファイルをlfsポインターに置き換えるコミットを追加します。

  1. 作業コピーを完全に消去します。下の強制追加と合わせて、.gitignoreパターンが原因でファイルが追加または削除されるのを防ぎます。

    git clean -dfx
git reset --hard
git checkout -- .

  2. ステージング領域にすべての削除を追加します。作業コピーは変更されません。

    git rm --cached -r .

  3. 作業コピーからすべてのファイルを再度読み取りました。これは基本的に前のコマンドを元に戻しますが、lfsフィルターを再評価します。 .gitignoreを無視するには、-fを使用します。存在するすべてのファイルは以前にチェックインされており、再び追加されるはずです。

    git add -f .

  4. ステージング領域には、以前に「ポインタがあったはずです」エラーを発生させたバイナリファイルのみが含まれるようになりました。

    git commit -m "moved files to lfs"
0
Archy

Git lfs 2.5.0以降、これを簡単にする新しいコマンドが利用可能になりました（ docs ）：

git lfs migrate import --no-rewrite "broken file.jpg" "another broken file.png" ...

これは、ファイルをgit lfsに「移行」します。gitlfsは、.gitattributesが、現時点ではそうではありません（これがエラーメッセージの理由です）。

--no-rewriteは、gitがこれを古いコミットに適用するのを防ぎ、代わりに単一の新しいコミットを作成します。

つかいます -m "commitmessage"は、そのコミットのcommitmessageを設定します。

0
karyon

明らかにエラーがどこからともなく現れる場合、これがチームで行うことです。

  1. その特定のタイプのファイルのlfsを無効にします（.gitattributesの変更またはSourceTreeメニューを使用）

  2. 変更は消え、代わりに.gitattributesに変更が表示されます。

  3. 問題を削除します。

    3.1 1つの解決策は、git reset --hardを実行することです。別の方法として、変更を破棄します。ファイルが再び表示されない場合があります。

    3.2.1前のソリューションが機能しない場合は、1と2を繰り返します。次に、（A）にあるこのブランチが、それらの迷惑なファイル以外のすべてを既にコミットしてプッシュしていることを確認します。次に、変更をコミットしますが、プッシュはコミットしません。

    3.2.2：別のブランチに移動（B）

    3.2.3：.gitattributesへのコミットを実行したローカルブランチ（A）を削除します。プッシュされていないコミットがあると言われても削除を強制します。コミットは忘れます（後でGCなどで削除できますが、エラーのあるファイルが大きくなければ大したことではありません）

    3.2.4：ブランチAを再度チェックアウトします。迷惑なファイルやLFS設定が正しい方法でセットアップされずに、リポジトリの以前のステータスがダウンロードされます。

それは常に機能します！

0
darkgaze

このエラーの考えられる原因の1つは、レポジトリに既に追加されているファイルに影響を与える.gitattributesに対するgit LFS関連の変更によるです。

（正確な再現手順はわかりませんが、以前はLFSファイルであるはずの非LFSファイルとしてコミットされていた.gitattributesの影響を新たに受けたファイルに触れると、問題が発生したようです。この問題は、ブランチを切り替えることで悪化しているように見えた、または少なくとも問題が解決するまでブランチを切り替えることが不可能になったようだ。）

この場合、このエラーが繰り返し発生するのを防ぐために、以下の手順を使用しました。

  1. ここにある他の回答のいずれかに従って、現在のブランチの問題を修正します（たとえば、キャッシュをクリアしてリセットします。 BheeMaの回答 が有効であることがわかりました。）
  2. メインブランチに移動し、git statusでコミットするものがないことを確認します
  3. git属性の変更をgitに強制的に再チェックさせ、「再適用」する

Ratata Tataの答え in 。gitattributesの変更を有効にする方法 ）

 git rm --cached -r .
 git add -A

警告：手順2で、コミットするものが何もないことを確認してください。上記の手順により、以前にバージョン管理されていないファイルが追加されるためです

  1. 結果をgit status（LFSポインターになるように関連ファイルのみを修正する必要があります。つまり、「ポインターであるはずのファイルに遭遇する可能性がある」エラーを引き起こす可能性があります）
  2. （オプションで、可能な場合はこの修正を他のすべてのブランチにマージ/リベースします。そうしないと、これらのブランチに切り替えるときにこのエラーが再びポップアップする可能性があります。 、影響を受けるファイルをコミットするだけでかまいません。）
0
sonny