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

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

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
    }

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

Avery Pennarun, Thu, Jul 24, 2008 21:57:03 +0200:

quoted

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

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

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

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.

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

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?

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

On Thu, 24 Jul 2008, Avery Pennarun wrote:

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

	-Daniel
*This .sig left intentionally blank*

Hi,

Daniel Barkalow wrote:

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

Regards,
  Stephan

-- 
Stephan Beyer [off-list ref], PGP 0x6EDDD207FCC5040F

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.

On 2008.07.24 15:57:03 -0400, Avery Pennarun wrote:

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