remote: warning: inexact rename detection was skipped due to too many files.

Any message that you see during a git push , that is prefixed with remote: like this, is coming not from your Git but from their Git. No settings you make in your own repository will affect it.1

If they—whoever is the "they" that is receiving your git push —had a normal everyday repository, your git push from your master would send them your commits and ask them to set their master to identify the same commit as your master . That either just succeeds right away (because the commit you've asked them to set is a descendant of the commit they already have as their master ) or fails right away (because it's not).

We can therefore conclude that they, whoever they are, have fancied up their repository to run some special action when your git push asks their Git to update their master . This special action of theirs is now running, and doing some sort of git diff command. (The action is probably through a Git hook, such as a pre-receive or update hook.)

It's their Git that needs its rename-limit adjusted, to handle the difference between ... well, we don't know what they're git diff -ing! We only know that they are running git diff ! So this is the point at which we have to guess. There are a couple of reasonable things they could be doing, and many more unreasonable things.

They are almost definitely doing:

git diff <hash1> <hash2>

The hash1 value might be the current value of their master . If so, you can run git fetch (or even just git ls-remote ) to see what hash ID their master represents. The hash2 value might be the hash ID of the commit in your repository that you call master , in which case you can just use your own name master .

If we get all of our guesses right, and also correctly guess at any settings they have set in their configuration, we might be able to reproduce whatever is going wrong in their pre-receive or update hook.

Of course, just being able to reproduce it doesn't enable us to fix it. Only they can actually fix the problem. At best, we could work around it, by pushing different commits.

The correct action at this point is to ask them what they are doing, why they are doing it, and whether you can improve that for them in some way. If that fails, then go down this semi-blind alley of guessing what they're doing, and why, and whether and how you can work around their blunders.

1Modern Git actually has a way to send particular variable = value settings from one Git to another during a git push . By default, these have no effect at all on the receiving Git, since otherwise you'd be able to trick existing, settings-naive Git receivers with these options. But we know they have some sort of script they're using, from a Git hook; this script might actually look for such settings.

These settings are totally free-form, though. Without some clue from them, there is no way for us to guess what settings might do something useful. So once again, the correct action at this point is to talk to them.