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

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jul 25, 2008, 19:16 UTC
Message-ID: <alpine.LNX.1.00.0807251509390.19665@iabervon.org>
In-Reply-To: <32541b130807241342h483169d7we955512879075161@mail.gmail.com>

On Thu, 24 Jul 2008, Avery Pennarun wrote:

Show 21 quoted lines

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

	-Daniel
*This .sig left intentionally blank*