Ostrzeżenie o „diff.renamelimit variable” podczas wykonywania polecenia git push

86

Wysyłam lokalne zatwierdzenie do zdalnego serwera git i otrzymałem następujące komunikaty ostrzegawcze:

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.

Ale tak naprawdę już ustawiłem diff.renamelimit na 0 (myślę, że zero oznacza nieograniczone, prawda?).

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

Więc co mam zrobić, aby uniknąć tego ostrzeżenia? Dzięki.

stid.smth
źródło

Odpowiedzi:

67

Dokumentacja nie wspomina 0 jako szczególnej wartości dla diff.renamelimit.
Dlatego powinieneś ustawić ten limit na zalecaną wartość.
Możesz też spróbować całkowicie wyłączyć wykrywanie zmiany nazwy. ( git config diff.renames 0)

Podobny przykład znajdziesz w tym poście na blogu „ Confluence, git, rename, merge oh my ... ”:

Jak już wspomniano, git próbuje wykryć zmiany nazw plików po tym fakcie, na przykład podczas używania git loglub git diff/merge.
Próbując wykryć zmiany nazw, git rozróżnia dokładne i niedokładne zmiany, przy czym pierwsza jest zmianą nazwy bez zmiany zawartości pliku, a druga zmianą nazwy, która może obejmować zmiany w zawartości pliku (np. Zmiana nazwy / przeniesienie klasy Java).
To rozróżnienie jest ważne, ponieważ algorytm wykrywania dokładnych zmian nazw jest liniowy i zawsze będzie wykonywany, podczas gdy algorytm wykrywania niedokładnej zmiany nazwy jest kwadratowy ( O(n^2)) i git nie próbuje tego robić, jeśli liczba zmienionych plików przekracza pewien próg (1000 na domyślna).

Ponieważ liczba plików, na które miała wpływ ostatnia reorganizacja, przekracza ten próg, git po prostu poddaje się i pozostawia rozwiązanie scalania deweloperowi. W naszym przypadku możemy jednak uniknąć ręcznego rozwiązywania scalania, zmieniając próg


Uwaga: Git 2.16 (Q1 2018) zmieni ten limit:

Historycznie rzecz biorąc, mechanizm diff do wykrywania zmian nazw miał zakodowany na stałe limit 32 tys. Ścieżek; jest to zniesione, aby umożliwić użytkownikom wymianę cykli z (prawdopodobnie) łatwiejszym do odczytania wynikiem.

Zobacz zatwierdzenie 8997355 (29 listopada 2017) autorstwa Jonathana Tan ( jhowtan) .
Zobacz commit 9268cf4 , commit 9f7e4bf , commit d6861d0 , commit b520abf (13 listopada 2017) autorstwa Elijah Newren ( newren) .
(Scalone przez Junio ​​C Hamano - gitster- w zobowiązaniu 6466854 , 19 grudnia 2017 r.)

diff: zdjąć cichy zacisk renameLimit

W zatwierdzeniu 0024a54 (Napraw sprawdzanie limitu wykrywania zmiany nazwy; wrzesień 2007, Git v1.5.3.2), wartość renameLimitzostała ograniczona do 32767.
Wydaje się, że miało to na celu po prostu uniknięcie przepełnienia liczb całkowitych w następujących obliczeniach:

num_create * num_src <= rename_limit * rename_limit

Chociaż można to również postrzegać jako zakodowane na stałe związane z ilością czasu procesora, który jesteśmy skłonni pozwolić użytkownikom, aby wydali git na obsługę zmian nazw.
Górna granica może mieć sens, ale niestety ta górna granica nie została przekazana użytkownikom ani nigdzie udokumentowana.

Chociaż duże limity mogą spowolnić działanie, mamy użytkowników, którzy byliby zachwyceni, gdyby mała zmiana pięciu plików została poprawnie wybrana, nawet jeśli musieliby ręcznie określić duży limit i czekać dziesięć minut na wykrycie zmian.

Istniejące skrypty i narzędzia używające znaku „ -l0” do kontynuowania pracy, traktując 0 jako specjalną wartość wskazującą, że limit zmiany nazwy ma być bardzo dużą liczbą.


Git 2.17 (Q2 2018) pozwoli uniknąć wyświetlania komunikatu ostrzegawczego w środku wiersza " git diff" wyjścia.

Zobacz zatwierdzenie 4e056c9 (16 stycznia 2018) autorstwa Nguyễn Thái Ngọc Duy ( pclouds) .
(Scalone przez Junio ​​C Hamano - gitster- w zatwierdzeniu 17c8e0b , 13 lutego 2018 r.)

diff.c: opróżnij stdoutprzed wydrukowaniem ostrzeżeń o zmianie nazwy

Wynik diff jest buforowany w FILEobiekcie i nadal może być częściowo buforowany, gdy drukujemy te ostrzeżenia (bezpośrednio do fd 2).
Wynik jest tak pomieszany

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

Pogarsza się, jeśli ostrzeżenie jest drukowane po wydrukowaniu kodów kolorów dla części wykresu. Otrzymasz ostrzeżenie w kolorze zielonym lub czerwonym.

Najpierw opróżnij stdout, więc zamiast tego możemy otrzymać coś takiego:

 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
źródło
79
git config merge.renameLimit 999999

Co merge.renameLimit średnią

Liczba plików do uwzględnienia podczas wykrywania zmiany nazwy podczas scalania; jeśli nie jest określony, domyślnie przyjmuje wartość diff.renameLimit .

źródło: https://git-scm.com/docs/git-merge

Serge Seletskyy
źródło
34
dlaczego to jest merge.renameLimitzamiast diff.renameLimit?
pgpb.padilla
@ pgpb.padilla bardzo podobny
Sandra K
4
git config diff.renameLimit 999999 (wstaw swój własny numer) działał dla mnie.
elarcoiris
1
Czy jest powód, dla którego ktoś mógłby nie chcieć tego maksymalizować? Dlaczego w ogóle istnieje limit? Tylko po to, aby uratować procesor przed szalenie dużymi fuzjami?
electrovir