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 log
ou 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 diff
sortie " ".
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 stdout
avant d'imprimer les avertissements de renommage
La sortie diff est mise en mémoire tampon dans un FILE
objet 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.
merge.renameLimit
au lieu dediff.renameLimit
?