summaryrefslogtreecommitdiff
path: root/cache-tree.c
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2009-07-13 14:41:12 -0700
committerJunio C Hamano <gitster@pobox.com>2009-07-14 13:50:29 -0700
commitf222abdeec7838891e79abd152c6cb67e532b68d (patch)
treec295583a8511deb7a7ee9803a7608cf48935c847 /cache-tree.c
parent4fe1a61973c82c459ac0a25cb5342d00d347dfd9 (diff)
downloadgit-f222abdeec7838891e79abd152c6cb67e532b68d.tar.gz
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>
Diffstat (limited to 'cache-tree.c')
0 files changed, 0 insertions, 0 deletions