multiple-commit cherry-pick?

> Is there any easy way to cherry pick a _range_ of commits from some other
> branch to the current branch, instead of just one?
> 
> I thought maybe git-rebase could be coerced to do this somehow, but I
> couldn't figure a way.

> On Thu, Nov 06, 2008 at 11:45:27AM +0900, Miles Bader wrote:
> > Is there any easy way to cherry pick a _range_ of commits from some other
> > branch to the current branch, instead of just one?
> > 
> > I thought maybe git-rebase could be coerced to do this somehow, but I
> > couldn't figure a way.
> 
> Rebase is exactly what you want.  Given something like this:
> 
> o--o--o--A--B--C--o--o--X
>     \
>      o--o--D
> 
> where you want A, B, C to go on top of D:
> 
> $ git checkout -b newbranch C
> $ git rebase --onto D ^A

> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> > git reset --hard C
> > git rebase --onto ORIG_HEAD A^
> 
> Is that safe...?  Doesn't git-rebase also set ORIG_HEAD?

>> > git reset --hard C
>> > git rebase --onto ORIG_HEAD A^
>> 
>> Is that safe...?  Doesn't git-rebase also set ORIG_HEAD?
>
> One of the first things rebase does is validating and resolving its
> arguments. And that's happening before any actions that would touch
> ORIG_HEAD.

> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> >> > git reset --hard C
> >> > git rebase --onto ORIG_HEAD A^
> >> 
> >> Is that safe...?  Doesn't git-rebase also set ORIG_HEAD?
> >
> > One of the first things rebase does is validating and resolving its
> > arguments. And that's happening before any actions that would touch
> > ORIG_HEAD.
> 
> Ah, I see.
> 
> Hmm, I guess using rebase --abort isn't a very good idea in this case
> though... :-/

>> Hmm, I guess using rebase --abort isn't a very good idea in this case
>> though... :-/
>
> Why not? I mean, ok, you end up at C, and not where you have been before
> the reset --hard, but there's the reflog to help you get back to
> whatever previous state of the branch it is that you want.

> Is there any easy way to cherry pick a _range_ of commits from some other
> branch to the current branch, instead of just one?
> 
> I thought maybe git-rebase could be coerced to do this somehow, but I
> couldn't figure a way.  [Using git-rebase would be nice because of all the
> useful tools it provides, e.g., the --abort, --continue, and -i options.]
> 

> 
> git format-patch --full-index --binary --stdout <range...> | git am -3
> 
> This will not work if you want to pick a list, not a range, of
> commits.

>> git format-patch --full-index --binary --stdout <range...> | git am -3
>>
>> This will not work if you want to pick a list, not a range, of
>> commits.
>
> Doesn't "--no-walk" + list commits individually work?
>
> So it _should_ be possible to pick a list of commits too. Although I think
> that git format-patch will reverse the order.

> On Thu, 6 Nov 2008, Alex Riesen wrote:
>> 
>> git format-patch --full-index --binary --stdout <range...> | git am -3
>> 
>> This will not work if you want to pick a list, not a range, of
>> commits.
>
> Doesn't "--no-walk" + list commits individually work?
>
> So it _should_ be possible to pick a list of commits too. Although I think 
> that git format-patch will reverse the order.

> Linus Torvalds <torvalds@linux-foundation.org> writes:
> 
> > On Thu, 6 Nov 2008, Alex Riesen wrote:
> >> 
> >> git format-patch --full-index --binary --stdout <range...> | git am -3
> >> 
> >> This will not work if you want to pick a list, not a range, of
> >> commits.
> >
> > Doesn't "--no-walk" + list commits individually work?
> >
> > So it _should_ be possible to pick a list of commits too. Although I think 
> > that git format-patch will reverse the order.
> 
> Or "git show --pretty=email $commit1 $commit2" ... piped to "am"?
> 

> On Fri, 7 Nov 2008, Alex Riesen wrote:
> > 
> > Does not work if there are ranges given :-/
> > It'd be very nice to have: git show #c1..$c2 $c3 $c4 $c5..$c6
> 
> Yeah, we've very fundamentally never supported that. Not for show, but 
> also not for anything else (ie "gitk a..b c..d" does _not_ give you two 
> ranges).
> 
> It's easy to see why once you understand what 'a..b' really means (ie it 
> just expands to '^a' and 'b'), and how it's not really a "range" operation 
> as much as a set operation that interacts with all the other arguments 
> too. But unless you're very aware of that, it can be surprising.
> 

> Linus Torvalds, Fri, Nov 07, 2008 19:08:36 +0100:
> > On Fri, 7 Nov 2008, Alex Riesen wrote:
> > > 
> > > Does not work if there are ranges given :-/
> > > It'd be very nice to have: git show #c1..$c2 $c3 $c4 $c5..$c6
> > 
> > Yeah, we've very fundamentally never supported that. Not for show, but 
> > also not for anything else (ie "gitk a..b c..d" does _not_ give you 
> > two ranges).
> > 
> > It's easy to see why once you understand what 'a..b' really means (ie 
> > it just expands to '^a' and 'b'), and how it's not really a "range" 
> > operation as much as a set operation that interacts with all the other 
> > arguments too. But unless you're very aware of that, it can be 
> > surprising.
> > 
> 
> Oh, I am. But it is just so convenient to have range support for 
> commands which just show commits. Besides, git-show just errors out, 
> instead of producing the commits like git-log does.

> On Sun, 9 Nov 2008, Alex Riesen wrote:
>>
>> Oh, I am. But it is just so convenient to have range support for
>> commands which just show commits. Besides, git-show just errors out,
>> instead of producing the commits like git-log does.
>
> Have fun implementing the support, and then explaining to users why this
> shows only one commit:
>
>        git show HEAD^..HEAD HEAD~10
>

> 2008/11/10 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> > On Sun, 9 Nov 2008, Alex Riesen wrote:
> >>
> >> Oh, I am. But it is just so convenient to have range support for
> >> commands which just show commits. Besides, git-show just errors out,
> >> instead of producing the commits like git-log does.
> >
> > Have fun implementing the support, and then explaining to users why this
> > shows only one commit:
> >
> >        git show HEAD^..HEAD HEAD~10
> >
> 
> for cs in HEAD^..HEAD HEAD~10; do
>   case "$cs"; in
>   *..*)
>      git format-patch --stdout "$cs"
>      ;;
>   *)
>      git show --pretty=email "$cs"
>      ;;
>   esac
> done
> 
> At least, this is what I have in mind and how I expect it to work.

> On Mon, 10 Nov 2008, Alex Riesen wrote:
> > for cs in HEAD^..HEAD HEAD~10; do
> >   case "$cs"; in
> >   *..*)
> >      git format-patch --stdout "$cs"
> >      ;;
> >   *)
> >      git show --pretty=email "$cs"
> >      ;;
> >   esac
> > done
> > 
> > At least, this is what I have in mind and how I expect it to work.
> 
> That is not the way git-show is implemented (it uses setup_revisions() to 
> check for validity and to parse the arguments), and I cannot think of any 
> way to make this work without ugly workarounds.

> On Mon, Nov 10, 2008 at 10:31:32PM +0100, Johannes Schindelin wrote:
> > On Mon, 10 Nov 2008, Alex Riesen wrote:
> > > for cs in HEAD^..HEAD HEAD~10; do
> > >   case "$cs"; in
> > >   *..*)
> > >      git format-patch --stdout "$cs"
> > >      ;;
> > >   *)
> > >      git show --pretty=email "$cs"
> > >      ;;
> > >   esac
> > > done
> > > 
> > > At least, this is what I have in mind and how I expect it to work.
> > 
> > That is not the way git-show is implemented (it uses setup_revisions() to 
> > check for validity and to parse the arguments), and I cannot think of any 
> > way to make this work without ugly workarounds.
> 
> Would it be possible to add "range" support to a subset of commands by
> using a git-range wrapper?
> 
> Hypothetical, pie-in-the-sky idea:
> 
> 	git range HEAD^..HEAD HEAD~10 -- show --pretty=email
> 	git range HEAD^..HEAD HEAD~10 -- log
> 	git range HEAD^..HEAD HEAD~10 -- cherry-pick

> So we _could_ do something like
> 
> 	git log {a..b} {c..d ^e}
> 
> and just declare that { $args } is a self-contained "subset", and 
> effectively becomes the same thing as "$(git rev-list $args)" but with 
> magic no-walking semantics (ie all walking is done only _within_ the { 
> }, not between different groups.
> 
> You literally _can_ do it right now that way:
> 
> 	git log --no-walk $(git rev-list HEAD~5..HEAD~3) $(git rev-list 
> 	HEAD~1..)
> 
> actually works, but that will hit argument size limits on many platforms 
> really quickly.
> 
> So we could make a '{ }' in the argument space basically do a SHA1 
> expansion of the range inside, and imply --no-walk. It's _not_ entirely 
> trivial, because we'd need to handle the fact that object flags are 
> sticky, and clear them in between invocations of multiple ranges, but 
> it's not _fundmanetally_ difficult. It's just that somebody would need 
> to do it.

> So we could make a '{ }' in the argument space basically do a SHA1 
> expansion of the range inside, and imply --no-walk. It's _not_ entirely 
> trivial, because we'd need to handle the fact that object flags are 
> sticky, and clear them in between invocations of multiple ranges, but it's 
> not _fundmanetally_ difficult. It's just that somebody would need to do 
> it.

> Linus Torvalds <torvalds@linux-foundation.org> writes:
> 
> > So we could make a '{ }' in the argument space basically do a SHA1 
> > expansion of the range inside, and imply --no-walk. It's _not_ entirely 
> > trivial, because we'd need to handle the fact that object flags are 
> > sticky, and clear them in between invocations of multiple ranges, but it's 
> > not _fundmanetally_ difficult. It's just that somebody would need to do 
> > it.
> 
> Wouldn't you lose the nice streaming output (iow short latency)?

> 
> but if you already do
> 
> 	gitk a..b
> 
> then you're _already_ doing a revision limiter and forcing the revision 
> walk to be synchronous, so there would be no interactivity downside 
> between 'a..b' and '{a..b}'.

> 
> 
> On Fri, 14 Nov 2008, Linus Torvalds wrote:
> > 
> > but if you already do
> > 
> > 	gitk a..b
> > 
> > then you're _already_ doing a revision limiter and forcing the revision 
> > walk to be synchronous, so there would be no interactivity downside 
> > between 'a..b' and '{a..b}'.
> 
> Btw, the biggest problem (I think) is actually non-simple ranges and just 
> the _syntax_ of these things.
> 
> It's entirely reasonable to want to group a more complex expression than 
> just a single range. IOW, something like
> 
> 	gitk {..origin/pu ^origin/next} {HEAD~5..HEAD~2}
> 
> to show a union of what is in 'pu' but not master or next, and the 
> symmetrical difference of the current merge. It's a perfectly sensible 
> thing to do. And we _can_ do it right now, just with a nasty syntax:
> 
> 	gitk --no-walk $(git rev-list ..origin/pu ^origin/next) $(git rev-list HEAD~5..HEAD~2)
> 
> actually works. But look again at how nasty it is to parse the '{x}' 
> version, because the '{..}' thing now spans multiple arguments. 

>
> So we _could_ do something like
>
> 	git log {a..b} [...]
>

> On Sun, 9 Nov 2008, Alex Riesen wrote:
>
>> Oh, I am. But it is just so convenient to have range support for 
>> commands which just show commits. Besides, git-show just errors out, 
>> instead of producing the commits like git-log does.
>
> Have fun implementing the support, and then explaining to users why this 
> shows only one commit:
>
> 	git show HEAD^..HEAD HEAD~10

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> Alex could also change the command to show the HEAD and HEAD~10, by 
> changing the way series of range parameters are evaluated by the 
> revision parsing machinery.  You take HEAD^..HEAD and come up with one 
> set (that has only one commit, HEAD), you take the next parameter 
> HEAD~10 and come up with another set (that also has only one commit, 
> HEAD~10, because show does not walk), then you take union.
> 
> I personally do not want to see that happen, though.  The way multiple
> "ranges" that come from separate command line parameters combine using set
> operator semantics is so useful to do something like...
> 
> 	git log ko/master..master ^maint
> 
> which is my way to ask "Which commits on master are the ones that I
> haven't pushed out?