Re: User's mailing list? And multiple cherry pick

[Theodore Tso <tytso@mit.edu>]

On Wed, Jun 04, 2008 at 10:11:33AM +0200, David wrote:
> Here is an example:
> 
> o--o--O master
>        \
>         o--o--X--X--X--X--o--o topic
> 
> I want to copy the "X" patches from the topic branch over to master.
> The other patches aren't appropriate for master for whatever reason.
> eg, temporary debugging hacks, but I fixed a few problems in master in
> the X patches and now want to apply them on top of master, and keep
> working on "topic"
> 
> I want to end up with a tree like this:
> 
> 
> o--o--O--X'--X'--X'--X' master
>        \
>         o--o--X--X--X--X--o--o topic
>
> After getting the branches like this, I would then (try to) rebase
> topic like this:
> 
> o--o--O--X'--X'--X'--X' master
>                       \
>                        o'--o'--o'--o' topic
> 


OK, so assume the tree looks like this:

 o--o--O master
        \
         1--2--3--4--5--6--7--8 topic

First do a "git checkout topic; git rebase --interactive master", and
reorder the topic branch so it looks like this:

 o--o--O master
        \
         3--4--5--6--1--2--7--8 topic

Now find the commit ID for commit #6 above, and assuming that it's
f1dead2f, run the command "git checkout master; git merge f1dead2f".
Now the graph looks like this:

 o--o--O--3--4--5--6 master
                    \
                     1--2--7--8 topic

You could also use the command:

	"git update-ref refs/heads/master f1dead2f"

which keeps HEAD pointing at the topic branch, but the reason why I
suggested the "git checkout master; git merge f1dead2f" is that the
commands are generally more familiar to git newcomers, and I usually
want to do a test build and run the regression tests on master to make
sure things are clean.


> I say try to, because rebase sometimes gets a lot of dumb (to me,
> maybe I'm not using git correctly) conflicts in cases like this, so I
> end up manually rebasing, by making a new topic branch off master,
> cherry picking into it off the old topic branch, and then removing the
> old branch. Another case where multiple cherry picks would be nice :-)

Note that in the above set of commands, summarized as:

1) "git checkout topic; git rebase --interactive master"
   1a)  "make; make check" to build and run regression tests on the 
   	reordered topic branch.
2) "git checkout master; git merge f1dead2f" (this should be a fast forward)
   2a)  "make; make check" to build and run regression tests on the 
   	updated master branch.

There may be indeed conflicts at the first "git rebase --interactive",
but that's just git being conservative.  Usually it really isnt that
hard to resolve the conflicts, git add the files which required
fixups, and then doing a "git rebase --continue".  And you will have
to do the manual fixup regardless of whether you use "git rebase" or
"git cherry-pick"; the git rebase is just a more automated way of
doing things.

Regards,

						- Ted