[PATCH] revert/cherry-pick: allow the last parameter to be -h

[PATCH] revert/cherry-pick: allow the last parameter to be -h

[Jonas Fonseca]

... to ask for the usage string.

Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
 builtin-revert.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/builtin-revert.c b/builtin-revert.c
index ea2f15b..7984aeb 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -61,6 +61,8 @@ static void parse_options(int argc, const char **argv)
 	}
 
 	arg = argv[argc - 1];
+	if (!strcmp(arg, "-h"))
+		usage(usage_str);
 	if (get_sha1(arg, sha1))
 		die ("Cannot find '%s'", arg);
 	commit = (struct commit *)parse_object(sha1);
-- 
1.5.2.rc3.800.ga489e-dirty

-- 
Jonas Fonseca

Re: [PATCH] revert/cherry-pick: allow the last parameter to be -h

[Alex Riesen]

Jonas Fonseca, Tue, May 22, 2007 23:29:45 +0200:
> +	if (!strcmp(arg, "-h"))
> +		usage(usage_str);

    $ git rev-list --usage
    usage: git-rev-list [OPTION] <commit-id>... [ -- paths... ]
      limiting output:
	--max-count=nr
	--max-age=epoch
    ...

Why should cherry-pick be different?

Re: [PATCH] revert/cherry-pick: allow the last parameter to be -h

[Junio C Hamano]

Alex Riesen <raa.lkml@gmail.com> writes:

> Jonas Fonseca, Tue, May 22, 2007 23:29:45 +0200:
>> +	if (!strcmp(arg, "-h"))
>> +		usage(usage_str);
>
>     $ git rev-list --usage
>     usage: git-rev-list [OPTION] <commit-id>... [ -- paths... ]
>       limiting output:
> 	--max-count=nr
> 	--max-age=epoch
>     ...
>
> Why should cherry-pick be different?

Good question.  FYI

	$ git rev-list --huh?

works equally well ;-)

Re: [PATCH] revert/cherry-pick: allow the last parameter to be -h

[Jonas Fonseca]

Junio C Hamano <junkio@cox.net> wrote Tue, May 22, 2007:
> Alex Riesen <raa.lkml@gmail.com> writes:
> 
> > Jonas Fonseca, Tue, May 22, 2007 23:29:45 +0200:
> >> +	if (!strcmp(arg, "-h"))
> >> +		usage(usage_str);
> >
> >     $ git rev-list --usage
> >     usage: git-rev-list [OPTION] <commit-id>... [ -- paths... ]
> >       limiting output:
> > 	--max-count=nr
> > 	--max-age=epoch
> >     ...
> >
> > Why should cherry-pick be different?
> 
> Good question.  FYI
> 
> 	$ git rev-list --huh?
> 
> works equally well ;-)

Because it is different?

   $ git revert --why-must-it-be-so-hard-to-learn-git-sometimes
   fatal: Cannot find '--why-must-it-be-so-hard-to-learn-git-sometimes'

Because, contrary to git-rev-list, git-revert/cherry-pick is considered
part of the porcelain? Because asking that question to every small UI
improvement is not very useful?

And yes I could spell out '--help', but it just seems weird that I need
to know the calling convention of git-revert (_and_ git-cherry-pick for
that matter) in order to get the usage string, because that was what I
wanted to know in the first place. Anyway, if you don't like it, please
just drop the patch. :)

-- 
Jonas Fonseca

Re: [PATCH] revert/cherry-pick: allow the last parameter to be -h

[Junio C Hamano]

Jonas Fonseca <fonseca@diku.dk> writes:

> Junio C Hamano <junkio@cox.net> wrote Tue, May 22, 2007:
>> Alex Riesen <raa.lkml@gmail.com> writes:
>> ...
>> > Why should cherry-pick be different?
>> 
>> Good question.  FYI
>> 
>> 	$ git rev-list --huh?
>> 
>> works equally well ;-)
>
> Because it is different?
>
>    $ git revert --why-must-it-be-so-hard-to-learn-git-sometimes
>    fatal: Cannot find '--why-must-it-be-so-hard-to-learn-git-sometimes'
>
> Because, contrary to git-rev-list, git-revert/cherry-pick is considered
> part of the porcelain?

No, I did not notice it until now but you are right.  The
command line argument parser for these commands is done somewhat
sloppily, compared to others.

How about doing something like this instead?

-- >8 --
Fix command line parameter parser of revert/cherry-pick

The parser was inconsistently done, in that it did not look at
the last command line parameter to see if it could be an unknown
option, although it was designed to notice unknown options if
they were given in positions the command expects to find them
(i.e. everything except the last parameter, which ought to be
<commit-ish>).  This prevented a very natural invocation

	$ git cherry-pick --help

from issuing the usage help.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

diff --git a/builtin-revert.c b/builtin-revert.c
index ea2f15b..80c348c 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -45,8 +45,10 @@ static void parse_options(int argc, const char **argv)
 	if (argc < 2)
 		usage(usage_str);
 
-	for (i = 1; i < argc - 1; i++) {
+	for (i = 1; i < argc; i++) {
 		arg = argv[i];
+		if (arg[0] != '-')
+			break;
 		if (!strcmp(arg, "-n") || !strcmp(arg, "--no-commit"))
 			no_commit = 1;
 		else if (!strcmp(arg, "-e") || !strcmp(arg, "--edit"))
@@ -59,7 +61,8 @@ static void parse_options(int argc, const char **argv)
 		else if (strcmp(arg, "-r"))
 			usage(usage_str);
 	}
-
+	if (i != argc - 1)
+		usage(usage_str);
 	arg = argv[argc - 1];
 	if (get_sha1(arg, sha1))
 		die ("Cannot find '%s'", arg);

Re: [PATCH] revert/cherry-pick: allow the last parameter to be -h

[Jonas Fonseca]

Junio C Hamano <junkio@cox.net> wrote Tue, May 22, 2007:
> Jonas Fonseca <fonseca@diku.dk> writes:
> 
> > Junio C Hamano <junkio@cox.net> wrote Tue, May 22, 2007:
> >> Alex Riesen <raa.lkml@gmail.com> writes:
> >> ...
> >> > Why should cherry-pick be different?
> >> 
> >> Good question.  FYI
> >> 
> >> 	$ git rev-list --huh?
> >> 
> >> works equally well ;-)
> >
> > Because it is different?
> >
> >    $ git revert --why-must-it-be-so-hard-to-learn-git-sometimes
> >    fatal: Cannot find '--why-must-it-be-so-hard-to-learn-git-sometimes'
> >
> > Because, contrary to git-rev-list, git-revert/cherry-pick is considered
> > part of the porcelain?
> 
> No, I did not notice it until now but you are right.  The
> command line argument parser for these commands is done somewhat
> sloppily, compared to others.
> 
> How about doing something like this instead?

FWIW, I like it. Sorry for my quick and dirty patch.

> -- >8 --
> Fix command line parameter parser of revert/cherry-pick
> 
> The parser was inconsistently done, [...]in that it did not look at
> the last command line parameter to see if it could be an unknown
> option, although it was designed to notice unknown options if
> they were given in positions the command expects to find them
> (i.e. everything except the last parameter, which ought to be
> <commit-ish>).  This prevented a very natural invocation
> 
> 	$ git cherry-pick --help
> 
> from issuing the usage help.

But --help is handled elsewhere, you meant -h ...

-- 
Jonas Fonseca

Re: [PATCH] revert/cherry-pick: allow the last parameter to be -h

[Junio C Hamano]

Jonas Fonseca <fonseca@diku.dk> writes:

> But --help is handled elsewhere, you meant -h ...

Quite true.  I meant --usage.