If you are working on a project and need to backport changes from one branch to another, you might get errors if the files modified on the original branch have been renamed on the target branch (this can happen regardless of whether you are trying to merge or cherry-pick your changes). Git might not automatically apply the changes to the equivalent (renamed) files.

There is an easy way to deal with this issue. You can set the value of merge.renameLimit to something very high by opening a terminal and running:

git config merge.renameLimit 99999999

This works because git always tries to detect file renames, but it does it by default only in a very limited way as the process can consume lots of memory and become very slow due to excessive paging. The command above increases the rename detection limit.

After you are done with the backporting, you can revert the modification done to merge.renameLimit by running:

git config --unset merge.renameLimit

If the process described above fails, or if you only have a few commits which account for all the changes you need to backport, you might consider patching each file individually on the target branch by executing the following command for each commit you need to backport (and each modified file):

git show <commit-sha1> --no-color -- path/to/old_name | patch path/to/new_name

This works provided you are working on a Linux environment. What it does is the following: it first prints all modifications done to old_filename and pipes them to the patch command to have them applied to new_filename. You can omit the --no-color flag if you have not configured git to use colors on its output.

The second technique is not a good long term solution for projects which have lots of equivalent files with different names across two (or more) branches, but for backporting small changes it can save lots of development time if for some reason changing the rename detection limit does not get the job done.