# one half of a rebase

5 messages from 2009-09-11 to 2009-09-12. Participants: Geoffrey Irving, Matthieu Moy, Alex Riesen, Paolo Bonzini.
Thread: https://gitlist.dev/t/20903

## Geoffrey Irving, 2009-09-11 17:25

Subject: one half of a rebase
Message-ID: <7f9d599f0909111025q42e3cdc6vba602b84c1d81215@mail.gmail.com>
URL: https://gitlist.dev/e/7f9d599f0909111025q42e3cdc6vba602b84c1d81215%40mail.gmail.com

```
If I'm on branch topic and do "git rebase master", git performs two operations:

1. Rewind the current head to master.
2. For each commit in topic that isn't in master, cherry pick it onto
the current head.

I would like to be able to do (2) as a separate operation.  For
example, if I start out on branch master and want to get all of
topic's commits on top of the current head, I currently do

    git checkout topic
    git rebase master
    git branch -d master
    git branch -m master

If I could do (2) as a separate operation, it would look something like

    git cherry-pick-all topic

which is simpler and faster since it avoids switching files back and
forth (master to topic and back).  Is there a robust way to achieve
the cherry-pick-all semantics with current commands?  If not, how
difficult would it be to partition rebase accordingly?

Thanks,
Geoffrey

```

## Matthieu Moy, 2009-09-11 18:39

Subject: Re: one half of a rebase
Message-ID: <vpqvdjpgwbv.fsf@bauges.imag.fr>
URL: https://gitlist.dev/e/vpqvdjpgwbv.fsf%40bauges.imag.fr
In-Reply-To: <7f9d599f0909111025q42e3cdc6vba602b84c1d81215@mail.gmail.com>

```
Geoffrey Irving <irving@naml.us> writes:

> If I could do (2) as a separate operation, it would look something like
>
>     git cherry-pick-all topic

I believe

  git rebase --onto master master topic
  git update-ref master topic

would do the trick.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

```

## Alex Riesen, 2009-09-11 21:10

Subject: Re: one half of a rebase
Message-ID: <81b0412b0909111410k3f3ebfaco393bb37ff5a6b5c1@mail.gmail.com>
URL: https://gitlist.dev/e/81b0412b0909111410k3f3ebfaco393bb37ff5a6b5c1%40mail.gmail.com
In-Reply-To: <7f9d599f0909111025q42e3cdc6vba602b84c1d81215@mail.gmail.com>

```
On Fri, Sep 11, 2009 at 19:25, Geoffrey Irving <irving@naml.us> wrote:
> If I could do (2) as a separate operation, it would look something like
>
>    git cherry-pick-all topic
>
> which is simpler and faster since it avoids switching files back and
> forth (master to topic and back).  Is there a robust way to achieve
> the cherry-pick-all semantics with current commands?  If not, how
> difficult would it be to partition rebase accordingly?

I have this in my .bashrc:

$ gcp3 ()
{
    git format-patch -k --stdout --full-index "$@" | git am -k -3 --binary
}

Then, while on master branch:

$ gcp3 master..topic

```

## Geoffrey Irving, 2009-09-12 02:23

Subject: Re: one half of a rebase
Message-ID: <7f9d599f0909111923v76e0f411n16555e7cdc0c3ed1@mail.gmail.com>
URL: https://gitlist.dev/e/7f9d599f0909111923v76e0f411n16555e7cdc0c3ed1%40mail.gmail.com
In-Reply-To: <81b0412b0909111410k3f3ebfaco393bb37ff5a6b5c1@mail.gmail.com>

```
On Fri, Sep 11, 2009 at 5:10 PM, Alex Riesen<raa.lkml@gmail.com> wrote:
> On Fri, Sep 11, 2009 at 19:25, Geoffrey Irving <irving@naml.us> wrote:
>> If I could do (2) as a separate operation, it would look something like
>>
>>    git cherry-pick-all topic
>>
>> which is simpler and faster since it avoids switching files back and
>> forth (master to topic and back).  Is there a robust way to achieve
>> the cherry-pick-all semantics with current commands?  If not, how
>> difficult would it be to partition rebase accordingly?
>
> I have this in my .bashrc:
>
> $ gcp3 ()
> {
>    git format-patch -k --stdout --full-index "$@" | git am -k -3 --binary
> }
>
> Then, while on master branch:
>
> $ gcp3 master..topic

Great!  That should work nicely.

Geoffrey

```

## Paolo Bonzini, 2009-09-12 14:38

Subject: Re: one half of a rebase
Message-ID: <4AABB253.2080200@gnu.org>
URL: https://gitlist.dev/e/4AABB253.2080200%40gnu.org
In-Reply-To: <7f9d599f0909111923v76e0f411n16555e7cdc0c3ed1@mail.gmail.com>

```
On 09/12/2009 04:23 AM, Geoffrey Irving wrote:
> On Fri, Sep 11, 2009 at 5:10 PM, Alex Riesen<raa.lkml@gmail.com>  wrote:
>> On Fri, Sep 11, 2009 at 19:25, Geoffrey Irving<irving@naml.us>  wrote:
>>> If I could do (2) as a separate operation, it would look something like
>>>
>>>     git cherry-pick-all topic
>>>
>>> which is simpler and faster since it avoids switching files back and
>>> forth (master to topic and back).  Is there a robust way to achieve
>>> the cherry-pick-all semantics with current commands?  If not, how
>>> difficult would it be to partition rebase accordingly?

As mentioned by Alex "git am -3" is basically parsing + the second part 
of rebase.  So, based on Alex's recipe, here is a possible alias for 
cherry-pick-all:

[alias]
	cherry-pick-all = "!f() { git format-patch -k --stdout --full-index 
`git symbolic-ref HEAD`..$1 | git am -k -3 --binary; }; f"

More useful (just because it is more generic) than "the second part of 
git rebase", a "sequencer" would be "the second part of git rebase -i", 
applying a custom script coming from stdin.  If that was present, git 
cherry-pick-all could be done like this:

git log --pretty=tformat:'pick %h' master..topic | git sequencer

And here is yet another alternative, that however would only work only 
if the patches applies perfectly:

git log --pretty=format:%h master..topic | xargs -rn1 git cherry-pick

Paolo

```