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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> On Wed, May 11, 2011 at 22:36, Jeff King <peff@xxxxxxxx> 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
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]