* one half of a rebase
@ 2009-09-11 17:25 Geoffrey Irving
2009-09-11 18:39 ` Matthieu Moy
2009-09-11 21:10 ` Alex Riesen
0 siblings, 2 replies; 5+ messages in thread
From: Geoffrey Irving @ 2009-09-11 17:25 UTC (permalink / raw)
To: git; +Cc: Dylan Simon
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: one half of a rebase
2009-09-11 17:25 one half of a rebase Geoffrey Irving
@ 2009-09-11 18:39 ` Matthieu Moy
2009-09-11 21:10 ` Alex Riesen
1 sibling, 0 replies; 5+ messages in thread
From: Matthieu Moy @ 2009-09-11 18:39 UTC (permalink / raw)
To: Geoffrey Irving; +Cc: git, Dylan Simon
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/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: one half of a rebase
2009-09-11 17:25 one half of a rebase Geoffrey Irving
2009-09-11 18:39 ` Matthieu Moy
@ 2009-09-11 21:10 ` Alex Riesen
2009-09-12 2:23 ` Geoffrey Irving
1 sibling, 1 reply; 5+ messages in thread
From: Alex Riesen @ 2009-09-11 21:10 UTC (permalink / raw)
To: Geoffrey Irving; +Cc: git, Dylan Simon
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: one half of a rebase
2009-09-11 21:10 ` Alex Riesen
@ 2009-09-12 2:23 ` Geoffrey Irving
2009-09-12 14:38 ` Paolo Bonzini
0 siblings, 1 reply; 5+ messages in thread
From: Geoffrey Irving @ 2009-09-12 2:23 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Dylan Simon
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: one half of a rebase
2009-09-12 2:23 ` Geoffrey Irving
@ 2009-09-12 14:38 ` Paolo Bonzini
0 siblings, 0 replies; 5+ messages in thread
From: Paolo Bonzini @ 2009-09-12 14:38 UTC (permalink / raw)
To: Geoffrey Irving; +Cc: Alex Riesen, git, Dylan Simon
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-09-12 14:38 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-09-11 17:25 one half of a rebase Geoffrey Irving
2009-09-11 18:39 ` Matthieu Moy
2009-09-11 21:10 ` Alex Riesen
2009-09-12 2:23 ` Geoffrey Irving
2009-09-12 14:38 ` Paolo Bonzini
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.