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

This is a total throw-away patch. I'm not going to re-send. Take it or 
not, I don't care, I spent more time writing this discussion than I did on 
the patch. I just happened to notice this behavior, and decided I probably 
would prefer this behavior. But it doesn't really matter in any kind of 
big picture.

And, admittedly, you can _already_ do this by just adding "--do-walk" 
whenever you specify a range. And equally admittedly, you can already 
confuse git by adding the "--no-walk" _after_ specifying the range, ie you 
can do this:

	git log HEAD~5.. --no-walk

and it will actually turn into a really odd way of saying "git show HEAD" 
(notice: _not_ "HEAD~5". HEAD). And even with this change you can do the 
reverse:

	git show HEAD~5.. --no-walk

it it will first implicitly turn off walking ("git show"), then it will 
implicitly turn it on again (the commit range triggers the code in this 
patch), and then _after_ it has seen the commit range it will explicitly 
turn off walking again.

In other words, regardless of this patch you can do crazy things. I really 
don't think anybody cares. This patch is not meant to disable crazy 
things, it's meant to enable a reasonably sane user behavior.

 revision.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/revision.c b/revision.c
index a31434b..9f5dac5 100644
--- a/revision.c
+++ b/revision.c

@@ -133,7 +133,7 @@ void mark_parents_uninteresting(struct commit *commit)
 static void add_pending_object_with_mode(struct rev_info *revs, struct object *obj, const char *name, unsigned mode)
 {
 	if (revs->no_walk && (obj->flags & UNINTERESTING))
-		die("object ranges do not make sense when not walking revisions");
+		revs->no_walk = 0;
 	if (revs->reflog_info && obj->type == OBJ_COMMIT &&
 			add_reflog_for_walk(revs->reflog_info,
 				(struct commit *)obj, name))

Hi,

On Mon, 13 Jul 2009, Linus Torvalds wrote:

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.

For some reason, I wrote exactly this patch some time ago, but I forgot 
why I did not send it.  Probably because I did not want to appear as a 
total moron in public.  Which apparently I end up doing anyway.

So count me in on the supporters' side of this patch,
Dscho