Предупреждение о «переменной diff.renamelimit» при выполнении git push

86

Я отправляю локальную фиксацию на удаленный сервер git и получаю следующие предупреждающие сообщения:

remote: warning: only found copies from modified paths due to too many files.
remote: warning: you may want to set your diff.renamelimit variable to at least 19824 and retry the command.

Но на самом деле я уже установил для diff.renamelimit значение 0 (я думаю, что ноль означает неограниченный, верно?).

$ git config --list
...
diff.renamelimit=0

Итак, что мне делать, чтобы избежать этого предупреждения? Спасибо.

stid.smth
источник

Ответы:

67

В документации не упоминается 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 (первый квартал 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

В фиксации 0024a54 (Исправлена ​​проверка предела обнаружения переименования; сентябрь 2007 г., Git v1.5.3.2) renameLimitбыло зафиксировано значение 32767.
Похоже, это было сделано для того, чтобы просто избежать целочисленного переполнения в следующем вычислении:

num_create * num_src <= rename_limit * rename_limit

Хотя это также можно рассматривать как жестко запрограммированное ограничение на количество процессорного времени, которое мы готовы разрешить пользователям указывать git на обработку переименований.
Верхняя граница может иметь смысл, но, к сожалению, эта верхняя граница не была сообщена пользователям и нигде не задокументирована.

Хотя большие ограничения могут замедлить работу, у нас есть пользователи, которые были бы в восторге, если бы небольшое изменение из пяти файлов было правильно выбрано, даже если им придется вручную указать большой лимит и подождать десять минут, пока переименования не будут обнаружены.

Существующие сценарии и инструменты, которые используют " -l0" для продолжения работы, обрабатывая 0 как особое значение, указывающее, что предел переименования должен быть очень большим.


Git 2.17 (второй квартал 2018 г.) не будет отображать предупреждающее сообщение в середине строки git diffвывода.

См. Commit 4e056c9 (16 января 2018 г.) Нгуен Тхай Нгок Дуй ( pclouds) .
(Объединено Junio ​​C Hamano - gitster- в коммите 17c8e0b , 13 февраля 2018 г.)

diff.c: flush 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 +-

Еще хуже, если предупреждение печатается после того, как цветовые коды для части графика уже напечатаны. Вы получите предупреждение зеленого или красного цвета.

Сначала очистите 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.
VonC
источник
79
git config merge.renameLimit 999999

Что merge.renameLimit среднее

Количество файлов, которые следует учитывать при выполнении обнаружения переименования во время слияния; если не указано, по умолчанию используется значение diff.renameLimit .

источник: https://git-scm.com/docs/git-merge

Серж Селецкий
источник
34
почему это merge.renameLimitвместо diff.renameLimit?
pgpb.padilla 03
@ pgpb.padilla очень похожа
Sandra K
4
git config diff.renameLimit 999999 (введите свой номер) работал у меня.
elarcoiris 01
2
Есть ли причина, по которой кто-то может не захотеть довести это до максимума? Почему вообще существует лимит? Просто чтобы спасти ваш процессор от безумно больших слияний?
электровир