From: Paolo Bonzini <bonzini@gnu.org>
Date: Sat, 12 Sep 2009 14:38:11 GMT
Subject: Re: one half of a rebase
Message-ID: <4AABB253.2080200@gnu.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