Re: [BUG?] git revert option parsing too lenient?

From: Jeff King <peff@peff.net>
Date: May 11, 2011, 20:48 UTC
Message-ID: <20110511204851.GA29146@sigill.intra.peff.net>
In-Reply-To: <BANLkTin5FMYJkeLTNeZ47jsXtVxvrLRL+Q@mail.gmail.com>

On Wed, May 11, 2011 at 10:44:48PM +0200, Sverre Rabbelier wrote:

Show 8 quoted lines

> On Wed, May 11, 2011 at 22:36, Jeff King <peff@peff.net> wrote:
> > So yeah, it's a bug, but it is a known one. The trouble is that fixing
> > it means splitting the revision options into a set of "these are OK for
> > picking a revision or range of revisions" and "other options", and
> > letting commands like revert use one set but not the other.
> 
> Doing the splitting doesn't sound that hard, I assume the real problem
> is getting the option parser to look through both tables?

No, it wouldn't be that hard. You'd split handle_revision_opt into two functions, and then probably callers of setup_revisions would pass in a flag to say whether which subset they were interested in.

Maybe the splitting isn't hard. But I suspect it is one of those "the devil is in the details" tasks where you will find that the options do not fit as plainly into categories as you want. But I might be wrong. And I don't want to discourage you from trying to work on it. :)

-Peff