My question is how can I use git-rebase -- or a similar command --
to actually copy the commits from one branch to another.
For example I have cloned the linux kernel repository and I have
the following branches:
The difference between v2.6.x-stable and v2.6.x-local are just a
few minor patches (which are not in the default kernel tree) and some
script files added to make the compilation and deployment easier for
my setup. Thus v2.6.x-local is an ancestor of v2.6.x-stable. Now when
v2.6.24 will arrive I would like to "copy" the commits from
v2.6.23-local to v2.6.24-local.
One solution would be to use:
git rebase --onto v2.6.24-local v2.6.23-stable v2.6.23-local
But this will not copy the commits, but actually move them. (And I
do not see anything about this case in the git rebase documentation,
or pointers to other commands similar to rebase.)
So how should this be done?
P.S.: The simplest solution would be to obtain the list of commits
and apply them with cherry-pick... But this is not that straight
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=
commit _before_ rebase.
Johan Herland, <email@example.com>