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

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

[sf]

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

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

[Johannes Schindelin]

Hi,

On Mon, 18 Feb 2008, sf wrote:

> git-rebase -p does not work when one of the changes is cherry-picked
> before rebase.
>
> [...]
> 
> The problem area is function pick_one_preserving_merges in
> git-rebase--interactive.sh:
> 
> [...]
>
> If a commit's parent is not applied during rebase (e.g. because it was 
> cherry-picked already) then it is not rewritten either.

That is right.  How about giving it a try yourself?

Hints: you need to write a sha-1 to "$REWRITTEN"/<commit> for every commit 
that was _not_ cherry-picked.  To do this, you could run the same rev-list 
as for $TODO, but without the --cherry-pick, and then filter with

	(cat "$TODO" "$TODO" "$ALLCOMMITS") | sort | uniq -u

For these commits, you need to find the ones with the same patch-id, but 
which are upstream.  You can achieve that by calling "git patch-id" for 
each upstream commit that was not in the to-be-rebased branch, and storing 
those mappings in a file.  Then, for each leftout commit, you grep in that 
file, and write to "$REWRITTEN"/<orig-commit>.

Oh, and you have to warn or error if there are two or more commits with 
the desired patch-id.

Alternatively, you can wait until Daniel has rewritten 
git-rebase--interactive in C, which shouldn't be too long, and work on 
that.  Should be easier and more efficient, too.

Ciao,
Dscho