gitで設定ファイルをコミットする前に、フィルタを使用してコメントを削除します。
$ cat .git/config
[filter "stripcomments"]
clean = "stripcomments"
$ cat .git/info/attributes
/etc/* filter=stripcomments
コミットされていないファイルがある場合は、色を変更するシェルプロンプトもあります。私に関連する部分は次のとおりです.zshrc
。
[[ -n "$(git status --porcelain 2> /dev/null | tail -n1)" ]] && git_c=220 || git_c=34
私が経験している問題は、コメントを追加してファイルを変更するときにフィルタがコメントを削除し、git用のファイルを変更しないでください。特に違いがないことを確認できますgit diff
。しかし、git status
ファイルが変更されたことを示すので、私のシェルにはコミットされていない変更を示す黄色のプロンプトが表示されます。
この問題を解決するには何を使うべきですか?
編集する:
さらに悪いことに、これは修正されたgit status
ファイルが表示されることです。これにより、git diff
何の変化も現れません。これを行うと、git commit
何もしないというメッセージが表示されます。
つまり、git status
変更されたファイルが表示されますが、コミットすることはできません。
答え1
git status
ファイルサイズを変更せずにコメントを変更した場合(たとえば、1文字を変更したり、2行の単一行コメントを使用して切り替えるなど)、ファイル全体の長さやフィルタ処理された結果を変更しないすべての項目は期待どおりに機能します。
同じサイズの変更された(mtime)ファイルの場合は、そのgit status
内容を読み取り、フィルタを実行して比較します。コメントの変更がフィルタリングされる限り、変更はありません。
ただし、ファイルサイズが異なる場合、git status
フィルタはまったく実行されず、ファイルの内容も検索されません。ファイルサイズだけを変更しても、git status
ファイルが変更されたと見なすのに十分です。
ファイル内容ではなくファイルサイズを比較するのが一般的な最適化です。この場合は悪いです。そしてドラッグできるオプションはないようです。
core.checkStat = minimal
ほとんどすべての機能を無効にすることがありますとは別にファイルサイズの確認。だから行き止まりの路地です。この問題に関連する他のオプションがある場合は見つかりません。
git status
したがって、行動を変える適切な解決策はありません。
まったく別のコマンドに切り替える必要があります(実行git diff
?git commit --dry-run
それ以外の場合は実際にコミットされませんか?)。これらのツールは変更を比較/コミットするために実際にファイルの内容を確認する必要があるため、フィルタを実行し、何もしません。それ以外の場合は、実行してgit add
gitのキャッシュファイルサイズを更新しますか? (提出関連なし)
別の(奇妙な)オプションは、ファイルサイズの問題を強制することです。テキストファイルの場合は、コメントを追加してから常に同じサイズになるようにファイルを切り捨てます。したがって、ファイルサイズは決して変更されず、git status
ファイルの内容を確認する必要があります。
これはgit status
あなたのユースケースに適していますが、実用的ではありません。
より根本的なアプローチは自己git
治癒です。
diff --git a/read-cache.c b/read-cache.c
index 35e5657877..4e087ca3f5 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -213,7 +213,7 @@ int match_stat_data(const struct stat_data *sd, struct stat *st)
#endif
if (sd->sd_size != (unsigned int) st->st_size)
- changed |= DATA_CHANGED;
+ changed |= MTIME_CHANGED;
return changed;
}
これはサイズ変更が単なる時間変更であるかのようになります(その後、後でファイルの内容の比較を開始します)。しかし、これはローカルでのみ機能し、非常に危険です。結局のところ、この機能はgitリポジトリの整合性を担うので、そのような変更が安全かどうかは簡単にはわかりません。
これを行う場合は、名前をFrankengitと指定し、リポジトリをまったく変更できないことを確認する必要があります(少なくとも--no-optional-locks
statusコマンドに追加)。
9年前も同じ質問が提起されました。
Gitメーリングリストディスカッション:
明らかに何も出ていませんが、この機能に興味がある場合は、とにかくメーリングリストについてもう一度考えてください。それ以外の場合、9年後も同じ問題が発生し続けます。 ;-)