multiple-commit cherry-pick?

multiple-commit cherry-pick?

[Miles Bader]

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.]

Thanks,

-Miles

-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: multiple-commit cherry-pick?

[Deskin Miller]

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

newbranch will have <...> --D--A--B--C

Hope that helps,
Deskin Miller

Re: multiple-commit cherry-pick?

[Björn Steinbrink]

On 2008.11.05 22:24:37 -0500, Deskin Miller wrote:
> 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

That should be A^ ;-)

> newbranch will have <...> --D--A--B--C

... and then you can merge newbranch into the existing branch that
references D, fast-forwarding the branch. And then newbranch can be
deleted.

If you don't want to use a temporary branch, you can also do (while on
the branch onto which you want to cherry-pick):

git reset --hard C
git rebase --onto ORIG_HEAD A^

Which should get you the same result, without using a temporary branch.

Björn

Re: multiple-commit cherry-pick?

[Miles Bader]

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?

-Miles

-- 
Twice, adv. Once too often.

Re: multiple-commit cherry-pick?

[Björn Steinbrink]

On 2008.11.06 21:14:18 +0900, Miles Bader wrote:
> 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. Though I'm not sure if it's always been like that.

Björn

Re: multiple-commit cherry-pick?

[Alex Riesen]

Miles Bader, Thu, Nov 06, 2008 03:45:27 +0100:
> 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.

Re: multiple-commit cherry-pick?

[Linus Torvalds]

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

Re: multiple-commit cherry-pick?

[Miles Bader]

>> 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.

Incidentally, the reason I like a rebase-based solution is that many
of the rebase features like -i, --abort, and --continue (after
conflict resolution) are very nice for the multi-cherry-pick case too,
and I'm already very familiar with their operation from using rebase.

[git-am seems to have some similar features, but I don't know how well
they work.]

-Miles

-- 
Do not taunt Happy Fun Ball.

Re: multiple-commit cherry-pick?

[Junio C Hamano]

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"?

Re: multiple-commit cherry-pick?

[Miles Bader]

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... :-/

Kind of a shame, since it's nice being to just abort the whole operation
if it turns out you did something wrong and aren't sure how to recover.

Thanks,

-Miles

-- 
Kilt, n. A costume sometimes worn by Scotchmen [sic] in America and Americans
in Scotland.

Re: multiple-commit cherry-pick?

[Alex Riesen]

Junio C Hamano, Fri, Nov 07, 2008 06:00:46 +0100:
> 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"?
> 

Does not work if there are ranges given :-/
It'd be very nice to have: git show #c1..$c2 $c3 $c4 $c5..$c6

Re: multiple-commit cherry-pick?

[Alex Riesen]

Miles Bader, Fri, Nov 07, 2008 05:38:16 +0100:
> [git-am seems to have some similar features, but I don't know how well
> they work.]

They work well.

Re: multiple-commit cherry-pick?

[Michael Radziej]

On Thu, Nov 06, Junio C Hamano wrote:
> Or "git show --pretty=email $commit1 $commit2" ... piped to "am"?

Or make git show write shell commands.

I often have commits that later need to be cherry-picked into other
branches. For these, I use a commit message that starts with the name of the
branch, like "implement-foo: make foo barfy". Later when I want to do the
cherry-picking, I use this:

git log t/whatever..master --reverse --pretty=tformat:'git cherry-pick %h #
%s' | sed 's/^\([^:]*\) \([^:]*\):/git checkout \2 \&\& \1/'

giving me output like:

git checkout implement-foo && git cherry-pick 90ce727 # make foo barfy
git checkout ...

... and I'm ready for cut'n'paste.



Michael


-- 
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49-911-9352-0 - Fax +49-911-9352-100
http://www.noris.de - The IT-Outsourcing Company
 
Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk - 
Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689

Re: multiple-commit cherry-pick?

[Björn Steinbrink]

On 2008.11.07 14:09:07 +0900, Miles Bader wrote:
> 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... :-/

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.

Björn

Re: multiple-commit cherry-pick?

[Miles Bader]

>> >> > git reset --hard C
>> >> > git rebase --onto ORIG_HEAD A^

>> 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.

I just mean it's not a trivial way to get back to the state before the
multi-cherry-pick -- you need to know the details of what's going on,
and handle the rest of the cleanup manually.

So, for instance, if you were to package up the above commands in a
shell script, the abort issue is one of those rough edges which would
prevent it from being as convenient as a real git command.  [A
hypothetical extension of the cherry-pick command to handle multiple
commits would presumably offer a "cherry-pick --abort" option that did
everything magically.]

-Miles

-- 
Do not taunt Happy Fun Ball.

Re: multiple-commit cherry-pick?

[Linus Torvalds]

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

Re: multiple-commit cherry-pick?

[Alex Riesen]

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.

Re: multiple-commit cherry-pick?

[Johannes Schindelin]

Hi,

On Sun, 9 Nov 2008, Alex Riesen wrote:

> 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.

Have fun implementing the support, and then explaining to users why this 
shows only one commit:

	git show HEAD^..HEAD HEAD~10

Ciao,
Dscho

Re: multiple-commit cherry-pick?

[Alex Riesen]

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.

Re: multiple-commit cherry-pick?

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> 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

I find what Alex says somewhat silly because show is always "no walk", and
range by definition means you need to walk.

But when you give that command line, 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?  By the way, I have pushed out maint already so I do
not want to see anything that is already in maint", where ko/master tracks
what I pushed out to the public repository at k.org; this query is used to
see if I can still rewrite commits when I find typo/thinko in them.

Re: multiple-commit cherry-pick?

[Johannes Schindelin]

Hi,

On Mon, 10 Nov 2008, Alex Riesen wrote:

> 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.

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.

Ciao,
Dscho

Re: multiple-commit cherry-pick?

[Johannes Schindelin]

Hi,

On Mon, 10 Nov 2008, Junio C Hamano wrote:

> 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?

Exactly one of my use cases, since we do not have ko/master,maint..master.

Ciao,
Dscho

Re: multiple-commit cherry-pick?

[Chris Frey]

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

Which would call the given command for each of the commits found in all
the specified ranges and lists.  git-range could have an internal list
of supported git subcommands that it would massage the parameter lists for.

I find this both elegant and ugly at the same time. :-)

- Chris

Re: multiple-commit cherry-pick?

[Johannes Schindelin]

Hi,

On Fri, 14 Nov 2008, Chris Frey wrote:

> 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

This is not really well defined is it?  What about

	git range HEAD -- log makefile

Where should it insert the "HEAD" argument?

Besides, I do not like how this muddies the semantics: if git range as you 
proposed it became part of Git, people _would_ get confused why "git range 
HEAD^..HEAD HEAD~10" interprets the range _differently_ from "git log 
HEAD^..HEAD HEAD~10".

Ciao,
Dscho

Re: multiple-commit cherry-pick?

[Linus Torvalds]

On Fri, 14 Nov 2008, Chris Frey wrote:
> 
> Would it be possible to add "range" support to a subset of commands by
> using a git-range wrapper?

It would be better to just extend the SHA-1 arithmetic. We could do it, no 
problem. It's just a SMOP.

For example, right now the arithmetic is entirely "flat", with no 
precedence, no nesting, nothing but a single level of set operations. We 
could extend it to be hierarchical.

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.

		Linus

Re: multiple-commit cherry-pick?

[Johannes Schindelin]

Hi,

On Fri, 14 Nov 2008, Linus Torvalds wrote:

> 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.

Well, do not forget the case

	git log ^HEAD^ {HEAD^..HEAD} $BLUB

Ciao,
Dscho

Re: multiple-commit cherry-pick?

[Junio C Hamano]

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)?

Re: multiple-commit cherry-pick?

[Linus Torvalds]

On Fri, 14 Nov 2008, Junio C Hamano wrote:
> 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)?

Oh, absolutely. So the '{x}' format would be not be a replacement for 
non-{} format - it would be an addition to.

But it's no different from 'a..b' in that sense: anything that sets 
'revs->limited' automatically forces a synchronous revision walk. So you'd 
be crazy to do

	gitk {HEAD}

because
 (a) there would be no point
 (b) it indeed loses the streaming data and would become synchronous.

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}'.

		Linus

Re: multiple-commit cherry-pick?

[Linus Torvalds]

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. 

			Linus

Re: multiple-commit cherry-pick?

[Francis Galiegue]

Le Friday 14 November 2008 17:11:41 Linus Torvalds, vous avez écrit :
[...]
>
> So we _could_ do something like
>
> 	git log {a..b} [...]
>

I don't know if you really meant this, but entering SHA1s as is at a shell 
prompt may have dangerous side effects... If not right now, then in (some not 
so distant time in) the future. Consider this (I use bash 3.2, maintained by 
Gentoo):

$ echo {a..c}
a b c

Who knows if some day they won't have the idea of, say, 
extending "{aeb32ca..ee23ff1}" to, well... You see what I mean.

-- 
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 6 83 87 78 75
Tel : +33 (0) 1 78 94 55 52
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris

Re: multiple-commit cherry-pick?

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]

On Fri, Nov 14, 2008 at 05:55:51PM +0000, Linus Torvalds wrote:
> 
> 
> 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. 

That would probably be a job that parseopt could take care of. to some
degree.

Also { } is a poor choice as it's an expansion thingy for many shells.
zsh even refuses ` { a.. b } ` as an argument, pretending there is a
syntax error at the closing brace. [ ] looks like a safer choice, it's
used for shells supporting arrays, but only when stuck after an
identifier which won't be our case ever, so we would be probably safe.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]