24

I have two branches for different versions - one for current development and another is long-time support several years old. As a consequence they differ significantly. I have some file that exists in both branches, but was renamed in development. One of fixes was made in development branch originally, but later found to be required in support branch as well. But cherry-pick reports that the file does not exist in support branch (because it was renamed in development and in support it has different name).

Contents of this particular file is similar, so it seems patch should be applied fine - if I can direct git what file it should apply it to. Is there a way (preferably in command line) to manually direct git to do what I need?

Ivan Danilov
  • 14,287
  • 6
  • 48
  • 66

2 Answers2

29

The cherry-pick command is using the same merge strategies as the merge command. The default recursive merge strategy is able to detect renames under normal circumstances, but it can fail if the files have diverged too much like in this case.

Apart from the low level index hacking outlined in the other answer, it might be possible to make it work simply by fiddling with the strategy options, for example increase the threshold for considering a similar file to be a renamed version (default is 50%):

git cherry-pick -Xrename-threshold=20% 0123sourcecommithash

Otherwise you could also always do it the manual way, i.e.

git format-patch 0123sourcecommithash -1

Then edit the created 0001-Commit-message-here.patch to change the file path and apply again on the target branch:

git am 0001-Commit-message-here.patch

It will retain all original commit messages, author names, dates etc. and might work as an easy one shot solution.

Yirkha
  • 12,737
  • 5
  • 38
  • 53
  • Yeah, that's an obvious and inconvenient way. I was hoping for something more elegant, though :) Thanks nevertheless – Ivan Danilov Sep 29 '15 at 13:37
  • Inconvenient but at least explicit, I'd say. I had another look and found one more way with fine tuning the merging strategy. And your link is interesting, thanks! – Yirkha Sep 29 '15 at 23:42
  • The answer makes sense and maybe works in some cases. But it did not work for me. The threshold did not helped, the file movement was not detected by git. The patch could not be applied. Maybe I did some mistakes on editing the patch. Does anyone know another way? I would prefer to use a 3-way merge tool instead of applying a patch because of better conflict resolution possbilities. – iuzuz Sep 27 '22 at 10:33
6

Remembered, where I have seen something similar. It was here. Linked script helps as well.

With the script you might do it with one-liner:

$ git merge-associate Old/Path/Original.txt :1:New/Path/Renamed.txt :3:New/Path/Renamed.txt

Same as if git merge-file supported :stage:filepath syntax without doing all the fuss around git show :1:New/Path/Renamed.txt > 1.txt; git show :3:New/Path/Renamed.txt > 3.txt described in Git FAQ.

Ivan Danilov
  • 14,287
  • 6
  • 48
  • 66