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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Feb 18, 2008, 15:06 UTC
Message-ID: <alpine.LSU.1.00.0802181458300.30505@racer.site>
In-Reply-To: <47B990FC.9090600@b-i-t.de>

Hi,

On Mon, 18 Feb 2008, sf wrote:

Show 12 quoted lines

> 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