Re: [PATCH] revert/cherry-pick: allow the last parameter to be -h
Junio C Hamano <junkio@cox.net> wrote Tue, May 22, 2007:
Show 26 quoted lines
> 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.
Show 13 quoted lines
> -- >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