Backport changes from renamed file

Question

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 production branch as a hot-fix. I try to use the cherry-pick. However it doesn't work because a changed file(s) in the fix was renamed in the trunk earlier during some refactoring which I don't want bring into production.

I don't want merge everything, but take only this commit. The cherry pick fails with "deleted by us" conflict (of course, the new file never even existed in the production branch).

What is the correct way to bring the changes into the old file?

Answer 1

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.

Answer 2

I'd use good old patch for this:

git show COMMIT_ID -- old/file/name.txt | patch new/file/name.txt

Answer 3

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.

Answer 4

I made a shell script that tries to do a cherry-pick while guessing file moves (it doesn't work if you renamed the file itself, only if you moved it to another folder): However: currently it will fail if the commit adds new files or if it itself rename files.

#!/bin/bash
#
# Attemps to guess file moves (rename of folders) when cherry-pick'ing.
# Gaspard van Koningsveld
#
[ "$1" == "" ] && echo "usage: $0 <commit-hash-to-cherry-pick>" && exit 1
TMP_PATCH_FILE="temp-cherry-pick-patch"
function abort() {
  echo "Aborting"
  "rm" -f "$TMP_PATCH_FILE"
  exit 1
}
function main() {
  echo "Retreiving commit patch..."
  "git" show "$1" > "$TMP_PATCH_FILE" || abort

  echo "Matching renamed files..."
  sedcmds=""
  for oldfile in $("grep" -E '(--- a|\+\+\+ b)' "$TMP_PATCH_FILE" | "cut" -c 7- | "sort" | "uniq"); do
    [ -f "$oldfile" ] && continue
    renamefound=0
    oldfilepart="$oldfile"
    while [ $renamefound -eq 0 ]; do
      possiblefiles=$("git" ls-files "**/$oldfilepart")
      if [ "$possiblefiles" != "" ]; then
        if [ $("wc" -l <<< "$possiblefiles") == "1" ]; then
          echo "  $oldfile > $possiblefiles"
          sedcmds="$sedcmds s|/$oldfile|/$possiblefiles|g;"
          break
        else
          echo "  ERROR: More than one rename possibility found for file $oldfile:"
          echo "$possiblefiles"
          abort
        fi
      fi
      prevoldfilepart="$oldfilepart"
      oldfilepart="${oldfilepart#*/}"
      if [ "$prevoldfilepart" == "$oldfilepart" ]; then
        echo "  ERROR: Could not find rename for $oldfile."
        abort
      fi
    done
  done
  echo "Renaming files in patch..."
  "sed" -i "$sedcmds" "$TMP_PATCH_FILE" || abort
  echo "Applying patch as new commit..."
  "sed" -i "s/^commit /From commit /;s/^Author: /From: /" "$TMP_PATCH_FILE" || abort
  "git" am -3 "$TMP_PATCH_FILE"

  "rm" -f "$TMP_PATCH_FILE"
}
main "$@"

Answer 5

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

Answer 6

If:

• You expected/hoped that Git would detect the move or rename of the file on trunk, but it didn't, and
• Your repository has a reasonable number of files

... 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%.