BUG: rebase -p after cherry-pick does not work

[sf <sf@b-i-t.de>]

Hello,

git-rebase -p does not work when one of the changes is cherry-picked
before rebase. Test case:

set -e -u
mkdir git
cd git
git init
for x in abc def ghi
do
  echo $x >$x
  git add $x
  git commit -m$x
done
git branch first
git reset --hard first~2
git cherry-pick first^
git branch second
EDITOR=: git rebase --verbose --interactive --preserve-merges \
second first
git status

The result for me is:

Initialized empty Git repository in .git/
Created initial commit fc8b37c: abc
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 abc
Created commit 3d6ca20: def
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 def
Created commit 4c5e07a: ghi
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 ghi
HEAD is now at fc8b37c... abc
Finished one cherry-pick.
Created commit 3d6ca20: def
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 def
Switched to branch "first"
Note: moving to "3d6ca204f4823bde7273a4bb83676055ae415224" which isn't a
local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
  git checkout -b <new_branch_name>
HEAD is now at 3d6ca20... def
Rebasing (1/1)
4c5e07a7107c87dec18244200ad1b52b76e71ea0
Fast forward to 4c5e07a7107c87dec18244200ad1b52b76e71ea0
Successfully rebased and updated refs/heads/first.
# On branch first
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       deleted:    ghi
#

The problem area is function pick_one_preserving_merges in
git-rebase--interactive.sh:

    # rewrite parents; if none were rewritten, we can fast-forward.
    fast_forward=t
    preserve=t
    new_parents=
    for p in $(git rev-list --parents -1 $sha1 | cut -d' ' -f2-)
    do
        if test -f "$REWRITTEN"/$p
        then
            preserve=f
            new_p=$(cat "$REWRITTEN"/$p)
            test $p != $new_p && fast_forward=f
            case "$new_parents" in
            *$new_p*)
                ;; # do nothing; that parent is already there
            *)
                new_parents="$new_parents $new_p"
                ;;
            esac
        fi
    done

If a commit's parent is not applied during rebase (e.g. because it was
cherry-picked already) then it is not rewritten either.

Regards

Stephan