threads / discuss / 14662

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

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

## tl;dr

9 messages between Jul 24, 2008 and Jul 25, 2008.

replies: 8people: 5as markdown or json

Avery Pennarun· Jul 24, 2008, 19:57 UTC · lore
Hi,

I often find myself being on a branch and wanting to do the equivalent of a series of cherry-picks from another branch into the current one. Unfortunately, "git cherry-pick" only does one patch at a time (which is very tedious), and "git rebase", which is much less tedious to use, seems to specializing in applying your current branch on top of another branch, not the other way around.

Currently I do something like this:
      git checkout -b tmp branch_with_interesting_stuff~5
      git rebase --onto mybranch branch_with_interesting_stuff~15
      git branch -d mybranch
      git branch -m tmp mybranch

But it seems a little complex when what I *really* want to type is something like:

      git cherry-pick
branch_with_interesting_stuff~15..branch_with_interesting_stuff~5

and have it give me a rebase-style UI in case of conflicts, etc. And of course, even more bonus points if I can get "rebase -i" functionality.

Am I missing an obvious syntax option here or is this not something normal people want to do?

I see that the second option to rebase sounds almost right:
       If <branch> is specified, git-rebase will perform an automatic git
       checkout <branch> before doing anything else. Otherwise it remains
       on the current branch.
So I could perhaps do this:
       git rebase --onto mybranch branch_with_interesting_stuff~15 \
              branch_with_interesting_stuff

But it sounds like that would rewrite branch_with_interesting_stuff instead of mybranch.

Thanks,
Avery
Alex Riesen· Jul 24, 2008, 20:13 UTC · re: Avery Pennarun · lore

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

Avery Pennarun, Thu, Jul 24, 2008 21:57:03 +0200:
Show 6 quoted lines
> I often find myself being on a branch and wanting to do the equivalent
> of a series of cherry-picks from another branch into the current one.
> Unfortunately, "git cherry-pick" only does one patch at a time (which
> is very tedious), and "git rebase", which is much less tedious to use,
> seems to specializing in applying your current branch on top of
> another branch, not the other way around.
Try this:
    $ type gcp3
    gcp3 is a function
    gcp3 ()
    {
	git format-patch -k --stdout --full-index "$@" | git am -k -3 --binary
    }
Avery Pennarun· Jul 24, 2008, 20:16 UTC · re: Alex Riesen · lore

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

On 7/24/08, Alex Riesen <raa.lkml@gmail.com> wrote:
Show 17 quoted lines
> Avery Pennarun, Thu, Jul 24, 2008 21:57:03 +0200:
>
> > I often find myself being on a branch and wanting to do the equivalent
>  > of a series of cherry-picks from another branch into the current one.
>  > Unfortunately, "git cherry-pick" only does one patch at a time (which
>  > is very tedious), and "git rebase", which is much less tedious to use,
>  > seems to specializing in applying your current branch on top of
>  > another branch, not the other way around.
>
> Try this:
>
>     $ type gcp3
>     gcp3 is a function
>     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.

Avery
Alex Riesen· Jul 24, 2008, 20:30 UTC · re: Avery Pennarun · lore

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

Avery Pennarun, Thu, Jul 24, 2008 22:16:06 +0200:
Show 9 quoted lines
> 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.

Avery Pennarun· Jul 24, 2008, 20:42 UTC · re: Alex Riesen · lore

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

On 7/24/08, Alex Riesen <raa.lkml@gmail.com> wrote:
Show 13 quoted lines
> 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?

Hmm, I suppose not, since git-am is a shellscript and cherry-pick is currently a builtin, so it would be kind of a step backwards.

Thanks,
Avery
Daniel Barkalow· Jul 25, 2008, 19:16 UTC · re: Avery Pennarun · lore

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

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*
Stephan Beyer· Jul 25, 2008, 19:25 UTC · re: Daniel Barkalow · lore

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

Hi,
Daniel Barkalow wrote:
Show 26 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).
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. :)

Regards,
  Stephan
-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
Alex Riesen· Jul 25, 2008, 20:00 UTC · re: Stephan Beyer · lore

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

Stephan Beyer, Fri, Jul 25, 2008 21:25:00 +0200:
Show 36 quoted lines
> 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.

Björn Steinbrink· Jul 25, 2008, 20:31 UTC · re: Avery Pennarun · lore

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

On 2008.07.24 15:57:03 -0400, Avery Pennarun wrote:
Show 25 quoted lines
> Hi,
> 
> I often find myself being on a branch and wanting to do the equivalent
> of a series of cherry-picks from another branch into the current one.
> Unfortunately, "git cherry-pick" only does one patch at a time (which
> is very tedious), and "git rebase", which is much less tedious to use,
> seems to specializing in applying your current branch on top of
> another branch, not the other way around.
> 
> Currently I do something like this:
> 
>       git checkout -b tmp branch_with_interesting_stuff~5
>       git rebase --onto mybranch branch_with_interesting_stuff~15
>       git branch -d mybranch
>       git branch -m tmp mybranch
> 
> But it seems a little complex when what I *really* want to type is
> something like:
> 
>       git cherry-pick
> branch_with_interesting_stuff~15..branch_with_interesting_stuff~5
> 
> and have it give me a rebase-style UI in case of conflicts, etc.  And
> of course, even more bonus points if I can get "rebase -i"
> functionality.
For "rebase -i", this should do:

git checkout mybranch git reset --hard interesting_stuff~5 git rebase -i --onto ORIG_HEAD interesting_stuff~5

Not as nice as the format-patch thing but at least it doesn't drop your braches' reflog like your version, and it provides "rebase -i" functionality.

Note that the ORIG_HEAD thing might require a recent git version, IIRC there were some patches to make rebase correctly handle that.

Björn

← back to recent threads