Re: [PATCH] Let 'git <command> -h' show usage without a git dir

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@xxxxxxxxx> writes:
> 
>> +/*
>> + * Let RUN_SETUP, USE_PAGER, and NEED_WORK_TREE take effect even if
>> + * passed the -h option.
>> + */
>> +#define H_IS_NOT_HELP	(1<<3)
> 
> Yuck.  Let's think of a way to avoid this ugliness.

Thank you. :)

> So I think the right approach is something like how you handled http-push;
> namely, check if the sole argument is "-h", and if so show help and exit.
> 
> 	Clarification. the following description only talks about "cmd -h"
> 	without any other options and arguments.
> 
> Such a change cannot be breaking backward compatibility for...
[...]
>  * "grep -h" cannot be asking for suppressing filenames as there is no
>    match pattern specified.

Okay, here’s a start.

-- %< --
Subject: Show usage string for 'git grep -h'

Clarification: the following description only talks about "git
grep -h" without any other options and arguments.

Such a change cannot be breaking backward compatibility.  "grep
-h" cannot be asking for suppressing filenames, as there is no
match pattern specified.

Signed-off-by: Jonathan Nieder <jrnieder@xxxxxxxxx>
---
Is the long usage information really what is wanted here?  (I would
think yes, since there is no other way to get that, but sometimes all
I want is a reminder of the non-optional arguments.)

Without something like the previous patch, the usage information is
captured by a pager.  I know this is an accidental thing (not all
commands send their -h output through a pager), but it is very
convenient and mitigates the first effect somewhat.  Should
whatever -h always use with a pager?

The -h output is very long, and since it goes to standard error,
"git grep -h | head" does not succeed in capturing the best of it.

Usage errors caught in the same function die() currently.  I was going
to switch them to usage_msg_opt(), but because of the long usage
message, that would cause the error message to scroll off the
screen...

So I am not totally happy with this.  But it is certainly an
improvement over the output from before:

$ git grep -h
fatal: no pattern given.

I’ll sleep on it.  Thank you for the advice.

Good night,
Jonathan

 builtin-grep.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/builtin-grep.c b/builtin-grep.c
index 1df25b0..01be9bf 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -788,6 +788,13 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
 		OPT_END()
 	};
 
+	/*
+	 * 'git grep -h', unlike 'git grep -h <pattern>', is a request
+	 * to show usage information and exit.
+	 */
+	if (argc == 2 && !strcmp(argv[1], "-h"))
+		usage_with_options(grep_usage, options);
+
 	memset(&opt, 0, sizeof(opt));
 	opt.prefix = prefix;
 	opt.prefix_length = (prefix && *prefix) ? strlen(prefix) : 0;
-- 
1.6.5.2

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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]