web-dev-qa-db-ja.com

「Gitインデックスの更新に失敗しました」と表示されるのはなぜですか

Windowsを使用しています。ファイルをステージングすると、このエラーが発生します。

Updating the Git index failed. A rescan will be automatically started to resynchronize git-gui.

LFからCRLFに変換されたファイルのリストが続きます

CRLF/LF Gitの使用クロスプラットフォームに関する問題をよく読んだ後、私は多かれ少なかれ何が起こっているのか理解しており、どのautocrlf設定が自分にとって最適かを判断しようとしています、しかし、なぜGitがインデックスの更新に失敗したと言っているのか理解できません。私の理解では、EOFが変換されたので、何が問題であり、なぜインデックスの更新が失敗したと通知されているのでしょうか。何か修正する必要がありますか(適切なautocrlf設定を選択する以外に)またはそのまま続行できますか

次に、[インデックスの続行]と[インデックスのロック解除]の2つのオプションがあります。これらの意味と、最善の行動方針は何ですか。

46
byronyasgur
git config --global core.autocrlf false

常に私の推奨事項でした( " WindowsのGit 1.6.4ベータ(msysgit)-UnixまたはDOSの回線終端 を参照)。

ただし、あなたの場合、「続行」することはできますが、この警告では、特定のファイルの変換は元に戻せない可能性があることを指摘しています。

core.safecrlf

Trueの場合、行末変換がアクティブなときにCRLFの変換が元に戻せるかどうかをgitチェックします。 Gitは、コマンドが直接または間接的に作業ツリーのファイルを変更するかどうかを確認します。たとえば、ファイルをコミットしてから同じファイルをチェックアウトすると、作業ツリーに元のファイルが生成されます。これがcore.autocrlfの現在の設定に当てはまらない場合、gitはファイルを拒否します。
変数を「警告」に設定できます。この場合、gitは元に戻せない変換についてのみ警告し、操作は続行します。

this thread で説明されているように、この警告を表示したくない場合は、core.safecrlffalseに設定できます。

Git guiのツールメニューからファイルを隠して、たとえば git config file を使用して、これらのツールにいくつかのオプションを追加することもできます。
興味があるのは、ツールごとに次のものを追加できることです。

guitool.<name>.norescan

ツールの実行が終了した後で、作業ディレクトリの変更を再スキャンしないでください。


アンロックインデックスについて少し詳しく説明していただけますか

このメッセージは index.tcl git-guiスクリプト で確認できます。これにより、インデックスの操作時にgit-guiが作成したindex.lockファイルが削除されます。
詳細は "lockfile API"ドキュメントページ で確認できます:

相互排除
新しいインデックスファイルを書き出すときは、まず新しいファイル$GIT_DIR/index.lockを作成し、新しいコンテンツをそのファイルに書き込み、名前を最終的な宛先$GIT_DIR/indexに変更します。
$GIT_DIR/index.lockを使用してO_EXCLファイルを作成しようとします。これにより、他の誰かがすでにインデックスファイルを更新しようとしているときに気づいて失敗することがあります。

46
VonC

私もこれに遭遇しましたcore.autocrlf設定はすでにfalseおよびcore.safecrlfは設定されていません。犯人は設定の設定だと思うdiff.astextplain.textconv

私が走ったときgit config --list、次の行が出力に表示されました:

diff.astextplain.textconv=astextplain

この設定は実際には警告/エラーに関連しているとは思いませんが、実行されている可能性のあるテキスト変換を調べるようになりました。オンラインと私のリポジトリで少し調べた後、リポジトリの。gitattributesファイルで次の行を発見しました。

* text=auto

[おそらくGitHubから。gitattributesファイルを取得しました。]

上記の行のみコメントが外されていて、さらに「自動」行末変換を処理するとalwaysが頭痛の種だったので、そのファイルをリポジトリから削除することにしました。その後、同じファイルをステージングしても、「Gitインデックスの更新に失敗しました」という警告/エラーが表示されなくなりました。

2
Kenny Evitt

TL; DR:この警告は、UNIXスタイルのテキストファイルをチェックインしたにもかかわらず、gitがWindowsスタイルのテキストファイルを返す可能性があることを意味します。

UNIXとWindowsでは、テキストファイルに改行を保存する方法が異なります。ウィキペディアには 異なるOSでの改行のリスト があります。

Windowsで次の操作を行うと、表示される警告は再現可能です。

  • 空のディレクトリにgitリポジトリを作成する
  • リポジトリの初期の空の状態を表すコミットを作成します。

    git commit --allow-empty -m "initial commit"
    
  • git config core.autocrlfgit config core.safecrlfを使用して、autocrlftrueに設定され、safecrlfが設定されていない(出力されない)ことを確認します。そうでない場合は、次のコマンドを使用して設定します

    git config core.autocrlf true
    git config --unset core.safecrlf
    
  • Notepad ++ を使用して、text.txtというテキストファイルをUNIX形式で書き込みます。少なくとも1つの改行があるファイルを書き込みます。これは、UNIXの行末を選択する方法です。 Notepad++ with the menu Edit - EOL Conversion opened

  • git add text.txt。警告メッセージが表示されます

    警告:LFは、text.txtでCRLFに置き換えられます。
    ファイルの元の行末は作業ディレクトリになります。

  • テキストファイルをコミットします。`gitcommit -m "UNIXで終わるファイルを追加します"

  • ツリーからチェックアウトすると、ファイルがどのように見えるかを確認します。まず、ファイルを作成する前のバージョンを確認します(1コミット前に戻ります)。ファイルtext.txtが作業ディレクトリから消えます:

    git checkout ~1
    
  • ファイルを作成した後、バージョンを復元します

    git checkout master
    

ファイルtext.txtが復元されます。しかし、それをNotepad ++で開き、Notepad ++の下部のステータス行で行末の形式を確認します。

The restored file which has now Windows-style CRLF endings

チェックアウトしたファイルにはWindowsスタイルの行末がありますが、コミットしたファイルにはUNIXスタイルのファイル終わりがありました!これは警告メッセージに関するものです:設定core.autocrlf=truecore.safecrlf=<unset>は、ツリーから復元されたファイルが、チェックしたファイルと異なる可能性があることを意味しますなぜなら、ファイルの末尾が異なる可能性があるためです。

0
akraf