Документация не упоминает 0 в качестве специального значения для diff.renamelimit.
Так что вам следует установить это ограничение на рекомендованное значение.
Или вы можете попробовать отключить обнаружение переименования.в целом.(git config diff.renames 0)
Подобный пример вы найдете в этом сообщении в блоге " Слияние, мерзавец, переименование, слияние, о, мой ... ":
Как уже упоминалось, git пытается обнаружить переименования файлов после этого факта, например, при использовании git log или git diff/merge.
При попытке обнаружить переименования git различает точное и неточное переименования, причем первое является переименованием без изменениясодержимое файла и последнее - переименование, которое может включать изменения в содержимом файла (например, переименование / перемещение класса Java).
Это различие важно, поскольку алгоритм определения точных переименований является линейным и всегда будетвыполняется, пока алгоритм неточного определения переименования является квадратичным (O(n^2)) и git не пытается сделать это, если число измененных файлов превышает определенный порог (по умолчанию 1000).
Как количество файловзатронутая недавней реорганизацией превышает этот порог, git просто сдается и оставляет разрешение на слияние доЭлектронный разработчик.В нашем случае мы можем избежать ручного разрешения слияния, хотя, изменяя порог
Примечание: Git 2.16 (Q1 2018) изменит этот предел:
Исторически, разницамашинное оборудование для обнаружения переименования имело жестко заданный предел 32 тыс. путей;это отменено, чтобы позволить пользователям совершать торговые циклы с (возможно) более легким для чтения результатом.
См. коммит 8997355 (29 ноября 2017) от Джонатан Тан (jhowtan).
См. commit 9268cf4 , commit 9f7e4bf , commit d6861d0 , commit b520abf (13 ноября 2017) от Элайджа Ньюрен (newren) .
(Объединено с Junio C Hamano - gitster - в коммит 6466854 , 19 декабря2017)
diff: убрать бесшумный зажим renameLimit
В commit 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 - in commit 17c8e0b , 13 Feb 2018)
diff.c: сброс stdout перед печатью предупреждений о переименовании
Вывод diff буферизируется в объекте FILE и можетЧастично буферизируется, когда мы печатаем эти предупреждения (непосредственно в fd 2).
Вывод запутывается следующим образом
worktree.c | 138 +-
worktree.h warning: inexact rename detection was skipped due to too many files.
| 12 +-
wrapper.c | 83 +-
Становится хуже, если предупреждение печатается послеЦветовые коды для части графика уже напечатаны.Вы получите предупреждение зеленым или красным цветом.
Сначала очистите стандартный вывод, чтобы мы могли получить что-то вроде этого:
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.