- In a Git repo, set up revision A, then revision B depending on A; then land A.
- Make a fresh clone of the repo (that doesn't already have the commit that B was based on), at a recent master that contains A.
- Run arc patch on B. (For example: arc patch D17607 in rGITTEST.)
arc patch produces a commit corresponding to B.
arc patch spews a mysterious error message from git cherry-pick:
$ time arc patch D17607 Created and checked out branch arcpatch-D17607. Created and checked out branch arcpatch-D17606. Checking patch thing... Applied patch thing cleanly. Cherry Pick Failed! Exception Command failed with error #1! COMMAND git cherry-pick 'arcpatch-D17606' STDOUT On branch arcpatch-D17607_1 Your branch is up-to-date with 'master'. You are currently cherry-picking commit fac7969. nothing to commit, working tree clean STDERR The previous cherry-pick is now empty, possibly due to conflict resolution. If you wish to commit it anyway, use: git commit --allow-empty Otherwise, please use 'git reset'
From a --trace, it looks like arc patch is patching in A first. It does the usual "make a commit at the original base" thing, tries to cherry-pick it, and then gets confused when Git warns that the cherry-pick is a no-op. If arc patch were clever here, it should probably just realize it doesn't need to do any of that, because A has already landed and the commit it landed as is an ancestor of HEAD, and skip straight to patching in B.