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

[Alex Riesen <raa.lkml@gmail.com>]

Stephan Beyer, Fri, Jul 25, 2008 21:25:00 +0200:
> Daniel Barkalow wrote:
> > > On 7/24/08, Alex Riesen <raa.lkml@gmail.com> wrote:
> > > > Avery Pennarun, Thu, Jul 24, 2008 22:16:06 +0200:
> > > > > On 7/24/08, Alex Riesen <raa.lkml@gmail.com> wrote:
> > > >
> > > > > >     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.