git の最新の Debian バージョン (私は 1.7.2.5 を使用しています) では.git/index、リポジトリを変更する必要があると思われる操作を実行していなくても、ファイルが不可解に変更される可能性があることに気付きました。(私のシェルはときどき実行git branchされるので、チェックアウトされたブランチを表示できますが、何も変更されません。) 変更により、.git/index元のファイルと同じ長さのファイルが作成されますが、ビットが異なります。 この変化の原因は何ですか?どうすればそれを止めることができますか?
(この変更は、 Unisonファイル シンクロナイザを台無しにするので不便です。)
インデックス ファイルはランダムに変更されるべきではありません。これがステージング ツリーであり、コミットのリポジトリと作業ツリーの間のバッファーです。効率化のために、作業ツリー (変更可能なチェックアウト済みファイル) に関するいくつかのメタデータも保存しstatusますdiff。そのような情報がどのような種類で保存されているかを確認するには、 を実行してみてくださいgit ls-files --debug。これにより、ファイルとディレクトリごとに次のように出力されます。
path/to/file
ctime: 1332898839:873326227
mtime: 1332898839:873326227
dev: 2052 ino: 4356685
uid: 1000 gid: 100
size: 3065 flags: 6c
そのため、ファイルがディスク上で何らかの方法で変更された場合、そのコンテンツとしてではなく、使用している i ノードなどの内部的なものが変更された場合、index次にインデックスが使用されたときにファイルの更新がトリガーされます。
git branch.git/HEADは、ファイルとファイル.git/refs/headsのみをチェックするため、インデックスを更新しませ.git/packed-refsん。インデックスや作業ツリーは気にしません。一方、インデックスを操作しますgit diff。git status
実験を行いました: 現在のindexファイルをコピーし、ファイルの新しいバージョンを作成して、新しい inode がそれに割り当てられるように (コピー、元のファイルを削除し、コピーの名前を元の名前に戻します)、実行git statusし、次に新しいインデックス ファイルを元のコピーと比較しました。2 つの点が変更されました: 影響を受けるファイルを含む行と、変更はファイル名の直前のバイトと、インデックス ファイルの最後の数バイト (おそらく最後のインデックス計算のタイムスタンプ) にありました。ファイル全体のサイズは変わりません。
問題に戻ると、自分でインデックスにアクセスするコマンドを実行していない場合は、それを実行する別のツールがある可能性があります。それは、IDE プラグインまたは Git リポジトリを認識し、ステータスをチェックするファイル ブラウザー拡張機能です。 git リポジトリの。または、ディスク デフラグ ユーティリティのように、ファイルがディスクに保存される方法を変更する別のプロセスがあります。
これはおそらくこの質問の著者にとって解決策ではないでしょうが、私の場合、etckeeper の毎日の自動コミット機能が原因でした。