Scott R Parish <srp@xxxxxxxxxxxx> writes:
> Signed-off-by: Scott R Parish <srp@xxxxxxxxxxxx>
> ---
> git.c | 5 ++---
> help.c | 4 ++--
> 2 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/git.c b/git.c
> index 853e66c..e1c99e3 100644
> --- a/git.c
> +++ b/git.c
> @@ -445,9 +445,8 @@ int main(int argc, const char **argv)
> if (!prefixcmp(argv[0], "--"))
> argv[0] += 2;
> } else {
> - /* Default command: "help" */
> - argv[0] = "help";
> - argc = 1;
> + /* The user didn't specify a command; give them help */
> + help_unknown_cmd("");
Sorry, but I fail to see why this is an improvement.
If you type "git<Enter>", before this patch we call cmd_help()
without help_cmd, which gives the usage string and lists common
commands, and exits with 1.
With this patch, you get "git: '' is not a git-command",
followed by list of common commands, and then the invocation
exits with 1.
I think "git help" should exit with 0. The user asked for help,
we give help, everything is going as expected and there is no
reason to exit with non-zero.
However, with the current implementation, these changes to
help.c also make "git<Enter>" to exit with 0 after it gives
help, which is not so nice (both "cvs" and "svn" without
parameter seem to exit with 1 and it sort of makes sense,
although I do not think it matters much). As a few datapoints,
"cvs -H" exits with 1 and "svn help" exits with 0.
So in short,
- "git" should retain the current behaviour (both output and
exit code).
- "git help" should retain the current output but probably
should exit with 0.
- Ditto for "git help -a".
-
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
