remote: warning: inexact rename detection was skipped due to too many files.
Любое сообщение, которое вы видите в течение git push, с префиксом remote:, подобным этому, приходит не от вашего Git, а от их Git. Никакие настройки, сделанные вами в вашем собственном репозитории, не повлияют на это. 1
Если бы они - кто бы ни был «они», которые получают ваш git push - имели бы обычный ежедневный репозиторий, ваш git push из вашего master отправил бы им ваши коммиты и попросил бы установить для их master значение идентифицируйте тот же коммит как ваш master. Это либо сразу удачно (потому что коммит, который вы просили их установить, является потомком коммита, который у них уже есть как master), либо сразу же завершается неудачей (потому что это не так).
Поэтому мы можем заключить, что они, кем бы они ни были, представили себе свой репозиторий, чтобы выполнить какое-то специальное действие, когда ваш git push просит их Git обновить их master. Это их специальное действие теперь выполняется и выполняет какую-то команду git diff. (Действие, вероятно, осуществляется через ловушку Git, такую как ловушка предварительного получения или обновления.)
Это их Git, который нуждается в корректировке предела переименования, чтобы справиться с разницей между ... ну, мы не знаем , что они git diff -ing ! Мы только знаем, что они работают git diff! Так что это точка, в которой мы должны угадать . Есть несколько разумных вещей, которые они могли бы делать, и много других неразумных вещей.
Они почти наверняка делают:
git diff <hash1> <hash2>
Значение hash1 может быть текущим значением их master. Если это так, вы можете запустить git fetch (или даже просто git ls-remote), чтобы увидеть, что представляет собой хеш-код их master. Значение hash2 может быть хэш-идентификатором коммита в вашем репозитории, который вы называете master, и в этом случае вы можете просто использовать свое собственное имя master.
Если мы все наши догадки верны, а также правильно угадываем при любых настройках они установили в их конфигурацию, мы могли бы воспроизвести все, что идет не так в их Предварительно получить или обновить хук.
Конечно, просто возможность воспроизвести его не позволяет нам это исправить. Только они могут реально исправить проблему. В лучшем случае мы могли бы обойти это, нажимая различные коммиты.
На данном этапе правильное действие - спросить их, что они делают, почему они это делают, и можете ли вы каким-то образом улучшить это для них. Если это не удается, , тогда идите по этому полузакрытому переулку, пытаясь угадать, что они делают и почему, а также можете ли вы и как обойти их промахи.
1 У современного Git действительно есть способ отправить определенные настройки variable = value из одного Git в другой во время git push. По умолчанию они не оказывают никакого влияния на принимающий Git, так как в противном случае вы могли бы обмануть существующие, наивные настройки Git-приемники с этими опциями. Но мы знаем, что у них есть какой-то скрипт, который они используют, из ловушки Git; этот скрипт может на самом деле искать такие настройки.
Хотя эти настройки абсолютно свободны. Без какой-либо подсказки мы не сможем угадать, какие настройки могут сделать что-то полезное. Итак, еще раз, правильное действие на этом этапе - поговорить с ними.