Ответ 1
документация не упоминает 0 как специальное значение для diff.renamelimit.
Поэтому вы должны установить этот предел на рекомендованное значение.
Или вы можете попробовать дезактивировать обнаружение переименования вообще. (git config diff.renames 0)
В этом блоге вы найдете аналогичный пример: Confluence, git, rename, merge oh my...":
Как уже упоминалось, git пытается обнаружить переименование файлов после этого факта, например, при использовании
git logилиgit diff/merge.
При попытке обнаружить переименования git различает точные и неточные имена переименований, причем первый из них является переименованием без изменения содержимого файла, а второй - переименованием, которое может включать в себя изменения в содержимом файла (например, переименование/перемещение класса Java).
Это различие важно, потому что алгоритм обнаружения точных переименований является линейным и всегда будет выполняться, если алгоритм определения неточного имени переименования квадратичен (O(n^2)) и git не пытается сделать это, если количество измененных файлов превышает определенный порог (по умолчанию 1000).Поскольку количество файлов, затронутых недавней реорганизацией, превышает этот порог, git просто отбрасывает и оставляет разрешение слияния до разработчика. В нашем случае мы можем избежать ручного разрешения слияния, хотя, изменив порог
Примечание: git 2.16 (Q1 2018) изменит этот предел:
Исторически сложилось, что механизм дифференциации для обнаружения переименования имел жестко закодированный предел 32k путей; это снимается, чтобы пользователи торговых циклов с (возможно) более легким для чтения результатом.
См. commit 8997355 (29 ноября 2017 г.) Джонатан Тан (jhowtan).
См. commit 9268cf4, совершить 9f7e4bf, commit d6861d0, совершить 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Хотя это также можно рассматривать как жестко привязанную к количеству CPU время, которое мы готовы разрешить пользователям сообщать git, чтобы тратить на обработку переименовывает.
Верхняя граница может иметь смысл, но, к сожалению, эта верхняя связанный ни с кем не сообщается пользователям и нигде не документируется.Хотя большие ограничения могут замедлить работу, у нас есть пользователи, которые будут ecstatic, чтобы иметь небольшое пять изменений файла, правильно вишня выбрана даже если им нужно вручную указать большой предел и подождать десять минут для переименования, которые будут обнаружены.
Существующие скрипты и инструменты, которые используют "-l0", продолжают работать, обрабатывая 0 как специальное значение, указывающее, что предел переименования должен быть очень большим.