Make 'git show' more useful
commitf222abdeec7838891e79abd152c6cb67e532b68d
authorLinus Torvalds <torvalds@linux-foundation.org>
Mon, 13 Jul 2009 21:41:12 +0000 (13 14:41 -0700)
committerJunio C Hamano <gitster@pobox.com>
Tue, 14 Jul 2009 20:50:29 +0000 (14 13:50 -0700)
treec295583a8511deb7a7ee9803a7608cf48935c847
parent4fe1a61973c82c459ac0a25cb5342d00d347dfd9
Make 'git show' more useful

For some reason, I ended up doing

git show HEAD~5..

as an odd way of asking for a log. I realize I should just have used "git
log", but at the same time it does make perfect conceptual sense. After
all, you _could_ have done

git show HEAD HEAD~1 HEAD~2 HEAD~3 HEAD~4

and saying "git show HEAD~5.." is pretty natural. It's not like "git show"
only ever showed a single commit (or other object) before either! So
conceptually, giving a commit range is a very sensible operation, even
though you'd traditionally have used "git log" for that.

However, doing that currently results in an error

fatal: object ranges do not make sense when not walking revisions

which admittedly _also_ makes perfect sense - from an internal git
implementation standpoint in 'revision.c'.

However, I think that asking to show a range makes sense to a user, while
saying "object ranges no not make sense when not walking revisions" only
makes sense to a git developer.

So on the whole, of the two different "makes perfect sense" behaviors, I
think I originally picked the wrong one. And quite frankly, I don't really
see anybody actually _depending_ on that error case. So why not change it?

So rather than error out, just turn that non-walking error case into a
"silently turn on walking" instead.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
revision.c