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.
merge.renameLimitzamiastdiff.renameLimit?