If you do this (and you are not an Emacs user who uses PAGER=cat in your *shell* buffer): $ git init Initialized empty Git repository in .git/ $ echo hello world >foo $ H=$(git hash-object -w foo) $ git tag -a foo-tag -m "Tags $H" $H $ echo $H 3b18e512dba79e4c8300dd08aeb37f8e728b8dad $ rm -f .git/objects/3b/18e5* $ git show foo-tag tag foo-tag Tagger: Junio C Hamano <gitster@xxxxxxxxx> Date: Sat Feb 16 10:43:23 2008 -0800 Tags 3b18e512dba79e4c8300dd08aeb37f8e728b8dad you do not get any indication of error. If you are careful, you would notice that no contents from the tagged object is displayed, but that is about it. If you run the "show" command without pager, however, you will see the error: $ git --no-pager show foo-tag tag foo-tag Tagger: Junio C Hamano <gitster@xxxxxxxxx> Date: Sat Feb 16 10:43:23 2008 -0800 Tags 3b18e512dba79e4c8300dd08aeb37f8e728b8dad error: Could not read object 3b18e512dba79e4c8300dd08aeb37f8e728b8dad Because we spawn the pager as the foreground process and feed its input via pipe from the real command, we cannot affect the exit status the shell sees from git command when the pager is in use (I think there is not much gain we can have by working it around, though). But at least it may make sense to show the error message to the user sitting in front of the pager, perhaps like this. What do people think? Have I overlooked any downsides? --- usage.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/usage.c b/usage.c index a5fc4ec..681b84a 100644 --- a/usage.c +++ b/usage.c @@ -4,12 +4,15 @@ * Copyright (C) Linus Torvalds, 2005 */ #include "git-compat-util.h" +#include "cache.h" static void report(const char *prefix, const char *err, va_list params) { char msg[256]; + FILE *outto = (pager_in_use() ? stdout : stderr); + vsnprintf(msg, sizeof(msg), err, params); - fprintf(stderr, "%s%s\n", prefix, msg); + fprintf(outto, "%s%s\n", prefix, msg); } static NORETURN void usage_builtin(const char *err) - 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