Re: multiple-commit cherry-pick?

[Junio C Hamano <gitster@pobox.com>]

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.