Документації не згадуються 0 як особлива цінність для diff.renamelimit.
Тож ви повинні встановити це обмеження до рекомендованого значення.
Або ви можете спробувати взагалі деактивувати виявлення перейменування. ( git config diff.renames 0)
Ви знайдете подібний приклад у цій публікації в блозі " Злиття, git, перейменування, злиття, о ... ":
Як уже зазначалося, git намагається виявити перейменування файлів після цього, наприклад, під час використання git logабо git diff/merge.
При спробі виявити перейменування git розрізняє точні та неточні перейменування, причому перше - це перейменування без зміни вмісту файлу, а друге - перейменування, яке може містити зміни у вмісті файлу (наприклад, перейменування / переміщення класу Java).
Ця різниця важлива, оскільки алгоритм виявлення точних перейменувань є лінійним і завжди буде виконуватися, тоді як алгоритм виявлення неточного перейменування є квадратичним ( O(n^2)), а git не намагається це зробити, якщо кількість файлів, що змінюються, перевищує певний поріг (1000 на за замовчуванням).
Оскільки кількість файлів, на які вплинула нещодавня реорганізація, перевищує цей поріг, git просто відмовляється і залишає дозвіл об’єднання розробнику. У нашому випадку ми можемо уникнути ручного дозволу злиття, хоча змінивши поріг
Примітка: Git 2.16 (Q1 2018) внесе зміни до цього обмеження:
Історично склалося, що механізм diff для виявлення перейменувань мав жорстко закодований ліміт у 32 тис. Шляхів; це скасовано, щоб дозволити користувачам торгувати циклами з (можливо) легшим для читання результатом.
Див. Коміт 8997355 (29 листопада 2017 р.) Джонатана Тана ( jhowtan) .
Див. Коміт 9268cf4 , коміт 9f7e4bf , коміт d6861d0 , коміт b520abf (13 листопада 2017 р.) Елайджа Ньюрен ( newren) .
(Об’єднано Junio C Hamano - gitster- у комітеті 6466854 , 19 грудня 2017)
diff: зняти безшумний затискач renameLimit
У коміті 0024a54 (Виправлено перевірку межі виявлення перейменування; вересень 2007 р., Git v1.5.3.2), renameLimitбуло зафіксовано 32767.
Це, здається, мало уникнути переповнення цілих чисел у наступних обчисленнях:
num_create * num_src <= rename_limit * rename_limit
Хоча це також можна розглядати як жорстко закодовану кількість процесорного часу, який ми готові дозволити користувачам сказати git витратити на обробку перейменувань.
Верхня межа може мати сенс, але, на жаль, ця верхня межа не була повідомлена користувачам і ніде не задокументована.
Незважаючи на те, що великі обмеження можуть уповільнити ситуацію, у нас є користувачі, яким буде надзвичайно приємно, якщо маленька п’ять файлів буде правильно вибиратись, навіть якщо їм доведеться вручну вказати великий ліміт і чекати десять хвилин, поки не буде виявлено перейменування.
Існуючі сценарії та інструменти, які використовують " -l0" для продовження роботи, обробляючи 0 як спеціальне значення, яке вказує на те, що обмеження перейменування має бути дуже великим.
Git 2.17 (Q2 2018) уникне показу попереджувального повідомлення посеред рядка " git diff" вихідних даних.
Див. Коміт 4e056c9 (16 січня 2018 р.) Нгуен pcloudsТхая Нгюка Дуя ( ) .
(Об’єднано Junio C Hamano - gitster- у комітеті 17c8e0b , 13 лютого 2018)
diff.c: змити stdoutперед друком попереджень про перейменування
Вихідні дані буферизуються в FILEоб'єкті і все ще можуть бути частково буферизовані, коли ми надрукуємо ці попередження (безпосередньо до fd 2).
Вихід зіпсований так
worktree.c | 138 +-
worktree.h warning: inexact rename detection was skipped due to too many files.
| 12 +-
wrapper.c | 83 +-
Погіршується, якщо попередження друкується після того, як кольорові коди для графічної частини вже надруковані. Ви отримаєте попередження зеленим або червоним кольором.
Спочатку змийте stdout, щоб замість цього ми могли отримати щось подібне:
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замістьdiff.renameLimit?