Re: git rebase to move a batch of patches onto the current branch

Stephan Beyer, Fri, Jul 25, 2008 21:25:00 +0200:

Daniel Barkalow wrote:

quoted

quoted

On 7/24/08, Alex Riesen [off-list ref] wrote:

quoted

Avery Pennarun, Thu, Jul 24, 2008 22:16:06 +0200:

quoted

On 7/24/08, Alex Riesen [off-list ref] wrote:

quoted

quoted

    gcp3 ()

 > >     {
 > >         git format-patch -k --stdout --full-index "$@" | git am -k -3 --binary
 > >     }
 >
 > But that'll give up when there are conflicts, right?  git-rebase lets
 > me fix them in a nice way.

No, it same as in rebase. You'll fix them and do "git am --resolved".
 See manpage of git am.

Hmm, cool.

So that command isn't too easy to come upon by accident.  If I wanted
to submit a patch to make this process a bit more obvious, would it
make sense to simply have git-cherry-pick call that sequence when you
give it more than one commit?

Before terribly long, we'll have "git sequencer", which should be easy to 
get to do the "rebase -i" thing with cherry-pick-style usage (somebody 
would just need to write code to generate the correct series of pick 
statements).

For simple cases this code could be something like:
git rev-list --reverse --cherry-pick --no-merges --first-parent <from>..<to> |
	sed 's/^/pick /' | git sequencer

(At least this is what I use relatively often.)

But as long as git sequencer is not in official git, this is not an
option. :)

Besides, that's longer than format-patch + am for the same from..to
range.