Знаю, что предел переименования по умолчанию равен 100 и может увеличить это значение, используя конфигурацию "diff.renamelimit config"
Что беспокоит, если эта конфигурация не настроена, произойдет ли неправильное слияние, любой недостающий код? Я пытаюсь объединить (git merge) 2 ветки, которые имеют огромные изменения.
Может кто-то проливает больше света на эту настройку конфигурации?
Ваш контент безопасен.
Как я понимаю, git фактически не имеет понятия о первоклассной работе rename (только bzr делает из больших 3 DVCS): mv - это сахар поверх базовый механизм, который в основном представляет собой add и a rm. Поскольку git может отслеживать контент, который изменяется во время таких операций, однако, он может использовать эвристику, чтобы угадать, когда add и a rm на самом деле являются mv. Поскольку это требует больше работы, чем просто отображение того, что действительно записано git - документы для git-diff объясняют, что он "требует O (n ^ 2) время обработки, где n - количество потенциальных целей переименования/копирования", - git не будет пытаться, когда задействовано слишком много файлов. Упомянутый параметр просто контролирует этот порог.
Если это кому-нибудь поможет, у меня было много файлов (сотни, если не тысячи) в одной ветке, которых еще не было в другой. Бег
$ git config merge.renamelimit 15345
сделал ошибку при слиянии
$ git merge master
.
.
.
warning: inexact rename detection was skipped due to too many files.
warning: you may want to set your merge.renamelimit variable to at least 15345 and retry the command.
У меня был такой же опыт, и я могу подтвердить, что сообщение - это просто предупреждение без последствий, за исключением нескольких надоедливых конфликтов слияния.