[解決済み] git push時のdiff.renamelimit変数に関する警告

質問

ローカルのコミットをリモートのgitサーバーにプッシュしているのですが、以下の警告メッセージが表示されます。

remote: warning: only found copies from modified paths due to too many files.
remote: warning: you may want to set your diff.renamelimit variable to at least 19824 and retry the command.

でも実は、すでにdiff.renamelimitを0に設定しています（0って無制限ってことですよね？）

$ git config --list
...
diff.renamelimit=0

では、この警告を回避するためにはどうしたらよいのでしょうか？ありがとうございます。

どのように解決するのですか？

この ドキュメント の特別な値として 0 を挙げていません。 diff.renamelimit .

ですから、その制限を推奨される値に設定する必要があります。

あるいは、リネーム検出を完全に解除してみるのもよいでしょう。( git config diff.renames 0 )

同様の例は、このブログ記事「"」にもあります。 Confluence, git, rename, merge oh my... "です。

すでに述べたように、git はファイルのリネームを事後的に検出しようとします。たとえば、ファイル名を変更する際に git log や git diff/merge .

リネームを検出しようとするとき、gitは正確なリネームと不正確なリネームを区別します。前者はファイルの内容を変更しないリネームで、後者はファイルの内容への変更を含むリネームです（例：Javaクラスのリネームや移動）。

この区別は、正確なリネームを検出するアルゴリズムは線形で常に実行されるのに対し、不正確なリネームを検出するアルゴリズムは二次関数であるため、重要です ( O(n^2) ) であり、変更されたファイルの数がある閾値 (デフォルトでは 1000) を超えると git はこれを実行しようとしません。

最近の再編成によって影響を受けたファイルの数がこの閾値を超えると、git は単に諦めて開発者にマージの解決を委ねます。私たちの場合は、閾値を変更することで、手動でのマージ処理を回避することができます。

---

注：Git 2.16 (2018年第1四半期) では、その制限が修正される予定です。

これまで、リネーム検出のための diff 機構には、32k パスのハードコードされた制限がありました。 ハードコードされた 32k パスの制限がありました。 これは、ユーザーが (おそらく) より読みやすい結果とサイクルを交換できるようにするために解除されます。

以下を参照してください。 コミット 8997355 (2017年11月29日)による ジョナサン・タン ( jhowtan ) .

参照 コミット 9268cf4 , コミット 9f7e4bf , コミット d6861d0 , コミット b520abf (2017年11月13日)によって イライジャ・ニューレン ( newren ) .

^{(によって統合されました。 ジュニオ・C・ハマノ--。 gitster -- で コミット 6466854 , 2017年12月19日)}

diff のサイレントクランプを削除します。 renameLimit

<ブロッククオート

で コミット 0024a54 (リネーム検出の制限チェックを修正; 2007年9月, Git v1.5.3.2) では、リネーム検出のための renameLimit が 32767 にクランプされました。

これは、次の計算で単に整数のオーバーフローを回避するためであったようです。

num_create * num_src <= rename_limit * rename_limit

これはまた、CPUの使用時間をハードコードしたものであるとも考えられます。 時間に対するハードコードされた制限とみなすこともできます。 のリネーム処理に費やすようユーザーに指示することを許可する、CPU時間のハードコードされた制限とみなすこともできます。

上限は意味があるかもしれませんが、残念ながらこの上限はユーザーには伝えられず はユーザーには伝えられず、どこにも文書化されていません。

大きな制限は物事を遅くする可能性がありますが、私たちのユーザーには、たとえ手動で変更しなければならないとしても、小さな 5 つのファイルの変更が正しくチェリー ピックされることに喜びを感じる人がいます。 たとえ手動で大きな制限を指定し、名前の変更が検出されるまで 10 分間待たなければならないとしても、小さな 5 つのファイルの変更が正しく選択されることに歓喜するユーザーがいます。

既存のスクリプトやツールで " -l0 " を使用している既存のスクリプトやツールは、0 を名前の変更の上限が非常に大きな数になることを示す特別な値として扱い、動作を継続します。

---

Git 2.17 (Q2 2018) では、" の行の途中で警告メッセージが表示されないようになります。 git diff "の出力で警告メッセージを表示しないようにします。

参照 コミット 4e056c9 (2018年1月16日)による Nguyễn Thái Ngọc Duy さん ( pclouds ) .

^{(によって統合されました。 ジュニオ・C・ハマノ--。 gitster -- で コミット 17c8e0b , 2018年2月13日）。}

diff.c フラッシュ stdout リネーム警告を表示する前に

<ブロッククオート

diff の出力は FILE オブジェクトにバッファリングされており に直接) 警告を出力する際に、部分的にバッファリングされる可能性があります。 fd 2 ).

出力はこのようにぐちゃぐちゃになっています。

worktree.c                                   |   138 +-
worktree.h        warning: inexact rename detection was skipped due to too many files.
                                             |    12 +-
wrapper.c                                    |    83 +-

グラフ部分のカラーコードがすでに印刷された後に警告が印刷されると、さらに悪化します。緑や赤で警告が表示されることになります。

まずstdoutをフラッシュして、代わりにこのようなものが出るようにします。

xdiff/xutils.c                               |    42 +-
xdiff/xutils.h                               |     4 +-
1033 files changed, 150824 insertions(+), 69395 deletions(-)
warning: inexact rename detection was skipped due to too many files.

---

Git 2.33 (2021 年第3四半期) で、" に関するドキュメントが公開されました。 git diff -l<n> " ^{( 人 )} そして diff.renameLimit が更新され、これらの制限のデフォルトが引き上げられました。

参照 コミット 94b82d5 , コミット 9dd29db , コミット 6623a52 , コミット 05d2c61 (2021 年 7 月 15 日) によるものです。 イライジャ・ニューレン ( newren ) .

^{(によって統合されました。 ジュニオ・C・ハマノ--。 gitster -- で コミット 268055b 2021年7月28日)}

diffcore-rename : を扱います。 rename_limit の0を無制限として扱う

^{署名入り: Elijah Newren}

<ブロッククオート

で コミット 8997355 (" diffcore-rename : make diff-tree -l0 mean -l", 2017-11-29, Git v2.16.0-rc0 --。 マージ に記載されている バッチ #10 ), -l0 には特別な魔法のような "large" 値が与えられていましたが、これはいくつかの用途には十分な大きさではありませんでした (次の例からわかるように コミット 9f7e4bf (" diff : のサイレントクランプを削除。 renameLimit "、2017-11-13、Git v2.16.0-rc0 --。 マージ に記載されている バッチ #10 ).

代わりに0（または負の値）を無制限として扱うようにし、これに言及するようにドキュメントを更新してください。

diff-options に含まれるようになりました。 を追加しました。 :

<ブロッククオート

なお、値0は無制限として扱われます。