Re: one half of a rebase

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 09/12/2009 04:23 AM, Geoffrey Irving wrote:
On Fri, Sep 11, 2009 at 5:10 PM, Alex Riesen<raa.lkml@xxxxxxxxx>  wrote:
On Fri, Sep 11, 2009 at 19:25, Geoffrey Irving<irving@xxxxxxx>  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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]