在执行 git push 时，警告“ different. renamlimit variable”

The documentation doesn't mention 0 as a special value for diff.renamelimit.
So you should set that limit to the value recommended.
Or you can try deactivating the rename detection altogether. (git config diff.renames 0)

You will find a similar example in this blog post "Confluence, git, rename, merge oh my...":

As already mentioned, git tries to detect file renames after that fact, for example when using git log or git diff/merge.
When trying to detect renames git distinguishes between exact and inexact renames with the former being a rename without changing the content of the file and the latter a rename that might include changes to the content of the file (e.g. renaming/moving a Java Class).
This distinction is important because the algorithm for detecting exact renames is linear and will always be executed while the algorithm for inexact rename detection is quadratic ( O(n^2) ) and git does not attempt to do this if the number of files changed exceeds a certain threshold (1000 by default).

As the number of files affected by the recent reorganisation exceeds this threshold, git simply gives up and leaves the merge resolution up to the developer. In our case we can avoid doing manual merge resolution though by changing the threshold

Note: Git 2.16 (Q1 2018) will amend that limit:

Historically, the diff machinery for rename detection had a hardcoded limit of 32k paths; this is being lifted to allow users trade cycles with a (possibly) easier to read result.

See commit 8997355 (29 Nov 2017) by Jonathan Tan (jhowtan).
See commit 9268cf4, commit 9f7e4bf, commit d6861d0, commit b520abf (13 Nov 2017) by Elijah Newren (newren).
^{(Merged by Junio C Hamano -- gitster -- in commit 6466854, 19 Dec 2017)}

diff: remove silent clamp of renameLimit

In commit 0024a54 (Fix the rename detection limit checking; Sept. 2007, Git v1.5.3.2), the renameLimit was clamped to 32767.
This appears to have been to simply avoid integer overflow in the following computation:

num_create * num_src <= rename_limit * rename_limit

Although it also could be viewed as a hard-coded bound on the amount of CPU time we're willing to allow users to tell git to spend on handling renames.
An upper bound may make sense, but unfortunately this upper bound was neither communicated to the users, nor documented anywhere.

Although large limits can make things slow, we have users who would be ecstatic to have a small five file change be correctly cherry picked even if they have to manually specify a large limit and wait ten minutes for the renames to be detected.

Existing scripts and tools that use "-l0" to continue working, treating 0 as a special value indicating that the rename limit is to be a very large number.

Git 2.17 (Q2 2018) will avoid showing a warning message in the middle of a line of "git diff" output.

See commit 4e056c9 (16 Jan 2018) by Nguyễn Thái Ngọc Duy (pclouds).
^{(Merged by Junio C Hamano -- gitster -- in commit 17c8e0b, 13 Feb 2018)}

diff.c: flush stdout before printing rename warnings

The diff output is buffered in a FILE object and could still be partially buffered when we print these warnings (directly to fd 2).
The output is messed up like this

worktree.c                                   |   138 +-
worktree.h        warning: inexact rename detection was skipped due to too many files.
|    12 +-
wrapper.c                                    |    83 +-

It gets worse if the warning is printed after color codes for the graph part are already printed. You'll get a warning in green or red.

Flush stdout first, so we can get something like this instead:

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.

With Git 2.33 (Q3 2021), documentation on "git diff -l<n>"^(man) and diff.renameLimit have been updated, and the defaults for these limits have been raised.

See commit 94b82d5, commit 9dd29db, commit 6623a52, commit 05d2c61 (15 Jul 2021) by Elijah Newren (newren).
^{(Merged by Junio C Hamano -- gitster -- in commit 268055b, 28 Jul 2021)}

diffcore-rename: treat a rename_limit of 0 as unlimited

^{Signed-off-by: Elijah Newren}

In commit 8997355 ("diffcore-rename: make diff-tree -l0 mean -l", 2017-11-29, Git v2.16.0-rc0 -- merge listed in batch #10), -l0 was given a special magical "large" value, but one which was not large enough for some uses (as can be seen from commit 9f7e4bf ("diff: remove silent clamp of renameLimit", 2017-11-13, Git v2.16.0-rc0 -- merge listed in batch #10).
Make 0 (or a negative value) be treated as unlimited instead and update the documentation to mention this.

diff-options now includes in its man page:

Note that a value of 0 is treated as unlimited.

git config merge.renameLimit 999999

What does merge.renameLimit mean

The number of files to consider when performing rename detection during a merge; if not specified, defaults to the value of diff.renameLimit.

source: https://git-scm.com/docs/git-merge

In case you aren't constantly running into this problem, but instead it's just a one-off thing then changing the global config from it's default value might be an overkill. I would suggest you simply use the -c option to set a special config just for this one command. Something like:

git -c "diff.renamelimit=19824" push