Avviso su "diff.renamelimit variabile" quando si esegue git push


87

Sto spingendo il commit locale sul server git remoto e ho ricevuto i seguenti messaggi di avviso:

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.

Ma in realtà ho già impostato diff.renamelimit su 0 (penso che zero significhi illimitato, giusto?).

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

Allora cosa devo fare per evitare questo avvertimento? Grazie.

Risposte:


67

La documentazione non menziona 0 come valore speciale per diff.renamelimit.
Quindi dovresti impostare quel limite sul valore consigliato.
Oppure puoi provare a disattivare del tutto il rilevamento della ridenominazione. (git config diff.renames 0 )

Troverai un esempio simile in questo post del blog " Confluence, git, rename, merge oh my ... ":

Come già accennato, git cerca di rilevare le ridenominazioni dei file dopo questo fatto, ad esempio quando si utilizza git logo git diff/merge.
Quando si tenta di rilevare le ridenominazioni, git distingue tra rinomine esatte e inesatte: la prima è una ridenominazione senza modificare il contenuto del file e la seconda una rinomina che potrebbe includere modifiche al contenuto del file (es. Rinominare / spostare una classe Java).
Questa distinzione è importante perché l'algoritmo per il rilevamento di ridenominazioni esatte è lineare e verrà sempre eseguito mentre l'algoritmo per il rilevamento di ridenominazioni inesatte è quadratic ( O(n^2)) e git non tenta di farlo se il numero di file modificati supera una certa soglia (1000 per predefinito).

Poiché il numero di file interessati dalla recente riorganizzazione supera questa soglia, git si arrende e lascia la risoluzione dell'unione allo sviluppatore. Nel nostro caso possiamo evitare di fare la risoluzione manuale del merge cambiando la soglia


Nota: Git 2.16 (Q1 2018) modificherà tale limite:

Storicamente, il meccanismo delle differenze per il rilevamento della ridenominazione aveva un limite hardcoded di 32k percorsi; questo viene revocato per consentire agli utenti di scambiare cicli con un risultato (possibilmente) più facile da leggere.

Vedere il commit 8997355 (29 nov 2017) di Jonathan Tan ( jhowtan) .
Vedere commit 9268cf4 , commit 9f7e4bf , commit d6861d0 , commit b520abf (13 novembre 2017) di Elijah Newren ( newren) .
(Fuso da Junio ​​C Hamano - gitster- in commit 6466854 , 19 dic 2017)

diff: rimuovere il morsetto silenzioso di renameLimit

Nel commit 0024a54 (Correzione del controllo del limite di rilevamento della ridenominazione; settembre 2007, Git v1.5.3.2), è renameLimitstato bloccato a 32767.
Questo sembra essere stato semplicemente per evitare l'overflow di numeri interi nel seguente calcolo:

num_create * num_src <= rename_limit * rename_limit

Sebbene possa anche essere visto come un limite hard-coded sulla quantità di tempo della CPU, siamo disposti a consentire agli utenti di dire a git di spendere per la gestione delle rinomine.
Un limite superiore può avere senso, ma sfortunatamente questo limite superiore non è stato comunicato agli utenti né documentato da nessuna parte.

Sebbene limiti elevati possano rallentare le cose, abbiamo utenti che sarebbero estasiati dal fatto che una piccola modifica di cinque file venga selezionata correttamente anche se devono specificare manualmente un limite elevato e attendere dieci minuti per il rilevamento delle ridenominazioni.

Script e strumenti esistenti che utilizzano " -l0" per continuare a lavorare, trattando 0 come un valore speciale che indica che il limite di ridenominazione deve essere un numero molto elevato.


Git 2.17 (Q2 2018) eviterà di mostrare un messaggio di avviso nel mezzo di una riga di "git diff output ".

Vedere commit 4e056c9 (16 gennaio 2018) di Nguyễn Thái Ngọc Duy ( pclouds) .
(Fuso da Junio ​​C Hamano - gitster- in commit 17c8e0b , 13 febbraio 2018)

diff.c: sciacquone stdout prima di stampare gli avvisi di rinomina

L'output di diff è bufferizzato in un FILEoggetto e potrebbe ancora essere parzialmente bufferizzato quando stampiamo questi avvisi (direttamente su fd 2).
L'output è incasinato in questo modo

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

La situazione peggiora se l'avviso viene stampato dopo che i codici colore per la parte del grafico sono già stati stampati. Riceverai un avviso in verde o rosso.

Svuota prima lo stdout, così possiamo ottenere qualcosa di simile invece:

 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

Che cosa significa merge.renameLimit media

Il numero di file da considerare quando si esegue il rilevamento della ridenominazione durante un'unione; se non specificato, il valore predefinito è diff.renameLimit .

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


35
perché questo merge.renameLimitinvece di diff.renameLimit?
pgpb.padilla

@ pgpb.padilla molto simile
Sandra K

4
git config diff.renameLimit 999999 (inserisci il tuo numero) ha funzionato per me.
elarcoiris

2
C'è un motivo per cui qualcuno potrebbe non voler massimizzare questo? Perché il limite esiste in primo luogo? Solo per salvare la tua CPU da unioni follemente grandi?
elettrovir

@ pgpb.padilla, il mio avviso diceva: avviso: potresti voler impostare la tua merge.renamelimitvariabile almeno su 1659 e riprovare il comando. Quindi, git config merge.renamelimit 10000sembra essere il comando giusto per me (sto impostando il limite a 10000 qui). Dopo averlo impostato, puoi rileggere l'impostazione con git config merge.renamelimit.
Gabriel Staples
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.