I have two branches: trunk, production. I have found a problem in trunk, made fix and committed it, pushed it. Now it was tested and I need do merge changes into the product
Faced with the same problem, I asked a colleague what he would do, and his instant response was:
git checkout production
git mv production-filename trunk-filename && git commit -m "Just fooling git"
git cherry-pick trunk-commit
git mv trunk-filename production-filename && git commit -m "Undo the damage"
# Now squash the 3 commits
git rebase -i HEAD~3
Worked like a charm for me.
If:
... then you should definitely consider changing your git config like this:
$ git config merge.renameLimit 999999
It is possible that during a merge/cherry-pick, git is hitting the default file check-limit (I think it's 400 or 1000 or something like that) before it is able to locate the suitable rename match. Upping this limit may cause merge/cherry-pick to take longer while it searches for your renamed file, but it can help avoid "deleted by us" merge-challenges.
That should do the trick, but if your renamed file was small and the changes between branches is significant, you might also play with the -X rename-threshold
setting, e.g. lowering it from the default 50% with -X rename-threshold=25%
.
I'd use good old patch for this:
git show COMMIT_ID -- old/file/name.txt | patch new/file/name.txt
To cherry pick changes to any number of files, in case of a directory rename between branches:
git diff ... | sed -e 's|<old dir>|<new dir>|' | git apply -
This is kind of tricky. For example, you could create a patch from a diff and apply it to the old file. But in the future to prevent these problems, I'd recommend to do fixes on the production branch and test it there first, then merge from production into trunk.
I experience the same problem and have tried to find a solution.
I solved by using a sequence of rebases. I've done no further tests than these so use at own risk!
If your're interested have a look at it on github:
https://github.com/fraschfn/cherry-pick