El documentation ne mentionne pas 0 comme valeur spéciale pour les diff.renamelimit .
Vous devez donc fixer cette limite à la valeur recommandée.
Ou vous pouvez essayer de désactiver complètement la détection des renommages. ( git config diff.renames 0 )
Vous trouverez un exemple similaire dans ce billet de blog " Confluence, git, renommer, fusionner oh my... " :
Comme déjà mentionné, git essaie de détecter les renommages de fichiers après coup, par exemple en utilisant git log o git diff/merge .
Lorsqu'il tente de détecter les renommages, git fait la distinction entre les renommages exacts et inexacts, le premier étant un renommage sans modification du contenu du fichier et le second un renommage qui peut inclure des modifications du 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é alors que l'algorithme de détection des renommages inexacts 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 la résolution manuelle des fusions en modifiant le seuil.
Remarque : Git 2.16 (Q1 2018) modifiera cette limite :
Historiquement, la machinerie diff pour la détection des renommages avait une limite codée en dur de 32k chemins ; cette limite est levée pour permettre aux utilisateurs utilisateurs d'échanger des cycles avec un résultat (éventuellement) plus facile à lire.
Voir commettre 8997355 (29 nov. 2017) par Jonathan Tan ( jhowtan ) .
Voir commettre 9268cf4 , commettre 9f7e4bf , commettre d6861d0 , commettre b520abf (13 nov. 2017) par Elijah Newren ( newren ) .
(fusionné par Junio C Hamano -- gitster -- sur commettre 6466854 , 19 décembre 2017)
diff : retirer la pince silencieuse de renameLimit
En commettre 0024a54 (Correction de la vérification de la limite de détection des renommages ; Sept. 2007, Git v1.5.3.2), la renameLimit a été fixé à 32767.
Il semble que ce soit simplement pour éviter un dépassement 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 CPU que nous sommes prêts à permettre aux utilisateurs de dire à git de dépenser pour gérer les renommages. renommages.
Une limite supérieure peut avoir du sens, mais malheureusement, cette limite supérieure n'a pas de sens. n'a pas été communiquée aux utilisateurs, ni documentée nulle part.
Bien que de grandes limites puissent rendre les choses lentes, nous avons des utilisateurs qui seraient qui seraient ravis qu'un petit changement de cinq fichiers soit correctement sélectionné, même s'ils doivent spécifier manuellement une limite élevée et attendre dix minutes pour que les renommages soient détectés.
Les scripts et outils existants qui utilisent " -l0 "pour continuer à travailler, en traitant 0 comme une valeur spéciale indiquant que la limite de renommage 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 diff " sortie.
Voir commettre 4e056c9 (16 janvier 2018) par Nguyen Thái Ngoc Duy ( pclouds ) .
(fusionné par Junio C Hamano -- gitster -- sur commettre 17c8e0b , 13 février 2018)
diff.c : chasse d'eau stdout avant d'imprimer les avertissements de renommage
La sortie diff est mise en mémoire tampon dans un FILE et pourrait encore être partiellement mis en mémoire tampon lorsque nous imprimons ces avertissements (directement à fd 2 ).
La sortie est brouillée comme ceci
worktree.c | 138 +-
worktree.h warning: inexact rename detection was skipped due to too many files.
| 12 +-
wrapper.c | 83 +-
La situation s'aggrave si l'avertissement est imprimé alors que les codes de couleur de la partie graphique sont déjà imprimés. Vous obtiendrez alors un avertissement en vert ou en rouge.
Videz d'abord le stdout, afin d'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.
Avec Git 2.33 (Q3 2021), la documentation sur " git diff -l<n> " ( homme ) y diff.renameLimit ont été mises à jour, et les valeurs par défaut de ces limites ont été augmentées.
Voir commettre 94b82d5 , commit 9dd29db , commettre 6623a52 , commettre 05d2c61 (15 juillet 2021) par Elijah Newren ( newren ) .
(fusionné par Junio C Hamano -- gitster -- sur commettre 268055b , 28 juillet 2021)
diffcore-rename : traiter un rename_limit de 0 comme illimité
Signé par : Elijah Newren
En commettre 8997355 (" diffcore-rename : make diff-tree -l0 mean -l", 2017-11-29, Git v2.16.0-rc0 -- fusionner répertorié dans lot n° 10 ), -l0 s'est vu attribuer une valeur magique spéciale "grande", mais qui n'était pas assez grande pour certaines utilisations (comme on peut le voir dans l'exemple ci-dessous). commettre 9f7e4bf (" diff : retirer la pince silencieuse de renameLimit ", 2017-11-13, Git v2.16.0-rc0 -- fusionner répertorié dans lot n° 10 ).
Faites en sorte que 0 (ou une valeur négative) soit traité comme illimité à la place et mettez à jour la documentation pour le mentionner.
diff-options inclut désormais dans son page de manuel :
Notez qu'une valeur de 0 est traitée comme illimitée.
