Coping commits from one branch to another

Previous thread: Using email between 2 developers to keep git repositories in sync by ab_lists on Tuesday, January 22, 2008 - 5:47 am. (9 messages)

Next thread: [PATCH] git-clone -s: document problems with git gc --prune by Miklos Vajna on Tuesday, January 22, 2008 - 2:03 pm. (3 messages)
From: Ciprian Dorin Craciun
Date: Tuesday, January 22, 2008 - 8:45 am

Hello all!

    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:
    -- v2.6.22-stable
    -- v2.6.23-local
    -- v2.6.23-stable
    -- v2.6.23-local

    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?

    Thanks,
    Ciprian Craciun.

    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
forward...
-

From: Johannes Schindelin
Date: Tuesday, January 22, 2008 - 9:03 am

Hi,


Very easy.  Do this before rebasing:

	git checkout -b v2.6.24-local v2.6.23-local

then proceed with

	git rebase --onto 2.6.24-stable v2.6.23-stable

Hth,
Dscho
-

From: Johan Herland
Date: Tuesday, January 22, 2008 - 9:07 am

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
Previous thread: Using email between 2 developers to keep git repositories in sync by ab_lists on Tuesday, January 22, 2008 - 5:47 am. (9 messages)

Next thread: [PATCH] git-clone -s: document problems with git gc --prune by Miklos Vajna on Tuesday, January 22, 2008 - 2:03 pm. (3 messages)