gitpushを実行するときの「diff.renamelimit変数」に関する警告


87

ローカルコミットをリモート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に設定しています(ゼロは無制限を意味すると思いますよね?)。

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

では、この警告を回避するにはどうすればよいでしょうか。ありがとう。

回答:


67

ドキュメントはのための特別な値として0を言及していませんdiff.renamelimit
したがって、その制限を推奨値に設定する必要があります。
または、名前変更検出を完全に無効にしてみてください。(git config diff.renames 0

このブログ投稿「Confluence、git、rename、merge oh my ...」にも同様の例があります:

すでに述べたように、gitは、たとえば、git logまたはを使用している場合など、その事後にファイル名の変更を検出しようとしますgit diff/merge
名前の変更を検出しようとすると、gitは正確な名前と不正確な名前を区別します。前者はファイルの内容を変更しない名前変更であり、後者はファイルの内容の変更(Javaクラスの名前変更/移動など)を含む可能性のある名前変更です。
正確な名前変更を検出するアルゴリズムは線形であり、不正確な名前変更検出のアルゴリズムが2次(O(n^2))である間は常に実行され、変更されたファイルの数が特定のしきい値(1000 byデフォルト)。

最近の再編成の影響を受けるファイルの数がこのしきい値を超えると、gitは単にあきらめて、マージの解決を開発者に任せます。私たちの場合、しきい値を変更することで、手動のマージ解決を回避できます。


注:Git 2.16(2018年第1四半期)はその制限を修正します:

歴史的に、名前変更検出用の差分機構には、ハードコードされた32kパスの制限がありました。これは、ユーザーが(おそらく)読みやすい結果でサイクルを交換できるようにするために解除されています。

Jonathan Tan()によるcommit 8997355(2017年11月29日)を参照してください。Elijah Newren()によるcommit 9268cf4commit 9f7e4bfcommit d6861d0commit b520abf(2017年11月13日)を 参照してください。(合併によりJunio C浜野- -6466854コミット、2017年12月19日)をjhowtan
newren
gitster

diff:のサイレントクランプを取り外します renameLimit

0024a54をコミット(名前変更検出限界チェック修正、2007年9月、Gitのv1.5.3.2)、renameLimit32767に固定した
だけで、次の計算でオーバーフロー整数避けるために行ったことがあるし、この表示されました:

num_create * num_src <= rename_limit * rename_limit

また、CPU時間のハードコードされた制限と見なすこともできますが、ユーザーが名前の変更の処理に費やすようにgitに指示できるようにします。
上限は理にかなっているかもしれませんが、残念ながら、この上限はユーザーに伝達されておらず、どこにも文書化されていません。

制限を大きくすると処理が遅くなる可能性がありますが、手動で大きな制限を指定して名前の変更が検出されるまで10分間待つ必要がある場合でも、5つの小さなファイルの変更を正しく選択することに夢中になっているユーザーがいます。

-l0」を使用して作業を続行する既存のスクリプトとツール。0を特別な値として扱い、名前変更の制限が非常に大きいことを示します。


Git 2.17(2018年第2四半期)git diffでは、「」出力の行の途中に警告メッセージが表示されなくなります。

参照してください4e056c9コミットにより(2018年1月16日)のグエンタイ・ゴックDuyと(pclouds
(合併によりJunio C浜野- gitster-17c8e0bコミット2018年2月13日)

diff.cstdout名前変更の警告を印刷する前にフラッシュする

差分出力は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.

82
git config merge.renameLimit 999999

merge.renameLimitとはどういう意味ですか

マージ中に名前変更の検出を実行するときに考慮するファイルの数。指定しない場合、デフォルトでdiff.renameLimitの値になります。

ソース:https//git-scm.com/docs/git-merge


35
なぜこれがmerge.renameLimit代わりにdiff.renameLimit
pgpb.padilla 2015

@ pgpb.padillaは非常に似ています
サンドラK

4
git config diff.renameLimit 999999(自分の番号を挿入)が機能しました。
elarcoiris 2018

2
誰かがこれを最大限に活用したくない理由はありますか?そもそもなぜ限界が存在するのですか?非常に大きなマージからCPUを節約するためだけですか?
electrovir

@ pgpb.padilla、私の警告は次のように述べています。警告:merge.renamelimit変数を少なくとも1659に設定して、コマンドを再試行することをお勧めします。だから、git config merge.renamelimit 10000私にとっては正しいコマンドのようです(ここでは制限を10000に設定しています)。設定したら、で設定を読み戻すことができますgit config merge.renamelimit
ガブリエルステープルズ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.