Actually, you're pretty much on the right track, already. git-rebase does=20
in fact _copy_ the commits onto the target branch. It's just that it also=20
moves the ref (i.e. branch name) along, so that the old commits are no=20
longer reachable. Consider the following:
git checkout -b v2.6.24-local_new v2.6.23-local
git rebase --onto v2.6.24-local v2.6.23-stable
This checks out a new branch (v2.6.24-local_new) that initially points at=20
the same commit as v2.6.23-local. We then rebase all the commits between=20
v2.6.23-stable and v2.6.24-local_new (which is the same as v2.6.23-local)=20
on top of the existing v2.6.24-local branch. v2.6.24-local_new will move=20
along and point to the last commit _after_ rebase, but you haven't moved=20
v2.6.23-local in the process, so it still points to the corresponding last=
=20
commit _before_ rebase.
Have fun!
=2E..Johan
=2D-=20
Johan Herland, <johan@herland.net>
www.herland.net