From: Jonas Fonseca <fonseca@diku.dk>
Date: Wed, 23 May 2007 06:57:50 GMT
Subject: Re: [PATCH] revert/cherry-pick: allow the last parameter to be -h
Message-ID: <20070523065750.GA25931@diku.dk>
In-Reply-To: <7v8xbg5bno.fsf@assigned-by-dhcp.cox.net>

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