Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. -- 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
