Avertissement sur la «variable diff.renamelimit» lors de l'exécution de git push

86

Je pousse le commit local sur le serveur git distant et j'ai les messages d'avertissement suivants:

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.

Mais en fait, j'ai déjà mis le diff.renamelimit à 0 (je pense que zéro signifie illimité, non?).

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

Alors, que dois-je faire pour éviter cet avertissement? Merci.

stid.smth
la source

Réponses:

67

La documentation ne mentionne pas 0 comme valeur spéciale pour diff.renamelimit.
Vous devez donc définir cette limite sur la valeur recommandée.
Ou vous pouvez essayer de désactiver complètement la détection de changement de nom. ( git config diff.renames 0)

Vous trouverez un exemple similaire dans ce billet de blog " Confluence, git, rename, merge oh my ... ":

Comme déjà mentionné, git essaie de détecter les noms de fichiers après cela, par exemple lors de l'utilisation de git logou git diff/merge.
Lorsqu'il essaie de détecter des renoms, git fait la distinction entre les renommés exacts et inexacts, le premier étant un changement de nom sans changer le contenu du fichier et le second un changement de nom qui pourrait inclure des changements dans le contenu du fichier (par exemple, renommer / déplacer une classe Java).
Cette distinction est importante car l'algorithme de détection des renommages exacts est linéaire et sera toujours exécuté tandis que l'algorithme de détection de renommage inexact est quadratique ( O(n^2)) et git ne tente pas de le faire si le nombre de fichiers modifiés dépasse un certain seuil (1000 par défaut).

Comme le nombre de fichiers affectés par la récente réorganisation dépasse ce seuil, git abandonne simplement et laisse la résolution de la fusion au développeur. Dans notre cas, nous pouvons éviter de faire une résolution de fusion manuelle en modifiant le seuil


Remarque: Git 2.16 (Q1 2018) modifiera cette limite:

Historiquement, la machinerie de diff pour la détection de changement de nom avait une limite codée en dur de 32k chemins; ceci est levé pour permettre aux utilisateurs d'échanger des cycles avec un résultat (éventuellement) plus facile à lire.

Voir commit 8997355 (29 novembre 2017) par Jonathan Tan ( jhowtan) .
Voir commit 9268cf4 , commit 9f7e4bf , commit d6861d0 , commit b520abf (13 novembre 2017) par Elijah Newren ( newren) .
(Fusionné par Junio ​​C Hamano - gitster- in commit 6466854 , 19 déc 2017)

diff: retirer la pince silencieuse de renameLimit

Dans le commit 0024a54 (Correction de la vérification de la limite de détection de renommage; sept. 2007, Git v1.5.3.2), le a renameLimitété limité à 32767.
Cela semble avoir été simplement pour éviter un débordement d'entier dans le calcul suivant:

num_create * num_src <= rename_limit * rename_limit

Bien que cela puisse également être considéré comme une limite codée en dur sur la quantité de temps CPU, nous sommes prêts à permettre aux utilisateurs de dire à git de passer à la gestion des renommés.
Une limite supérieure peut avoir un sens, mais malheureusement cette limite supérieure n'a été ni communiquée aux utilisateurs, ni documentée nulle part.

Bien que de grandes limites puissent ralentir les choses, nous avons des utilisateurs qui seraient ravis de voir un petit changement de cinq fichiers correctement sélectionné même s'ils doivent spécifier manuellement une grande limite et attendre dix minutes pour que les changements de noms soient détectés.

Scripts et outils existants qui utilisent " -l0" pour continuer à travailler, traitant 0 comme une valeur spéciale indiquant que la limite de changement de nom doit être un très grand nombre.


Git 2.17 (Q2 2018) évitera d'afficher un message d'avertissement au milieu d'une ligne de git diffsortie " ".

Voir commit 4e056c9 (16 janvier 2018) par Nguyễn Thái Ngọc Duy ( pclouds) .
(Fusionné par Junio ​​C Hamano - gitster- in commit 17c8e0b , 13 févr.2018 )

diff.c: rincer stdoutavant d'imprimer les avertissements de renommage

La sortie diff est mise en mémoire tampon dans un FILEobjet et pourrait encore être partiellement mise en mémoire tampon lorsque nous imprimons ces avertissements (directement dans fd 2).
La sortie est foirée comme ça

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

Cela empire si l'avertissement est imprimé après que les codes de couleur de la partie graphique sont déjà imprimés. Vous recevrez un avertissement en vert ou en rouge.

Videz d'abord stdout, afin que nous puissions obtenir quelque chose comme ceci à la place:

 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.
VonC
la source
79
git config merge.renameLimit 999999

Qu'est - ce que merge.renameLimit moyenne

Le nombre de fichiers à prendre en compte lors de la détection de changement de nom lors d'une fusion; s'il n'est pas spécifié, la valeur par défaut est diff.renameLimit .

source: https://git-scm.com/docs/git-merge

Serge Seletskyy
la source
34
pourquoi est-ce merge.renameLimitau lieu de diff.renameLimit?
pgpb.padilla
@ pgpb.padilla très similaire
Sandra K
4
git config diff.renameLimit 999999 (insérez votre propre numéro) a fonctionné pour moi.
elarcoiris
1
Y a-t-il une raison pour laquelle quelqu'un pourrait ne pas vouloir maximiser cela? Pourquoi la limite existe-t-elle en premier lieu? Juste pour sauver votre CPU de fusions incroyablement volumineuses?
electrovir