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

From: Jeff King <peff@peff.net>
Date: May 11, 2011, 20:36 UTC
Message-ID: <20110511203645.GB28742@sigill.intra.peff.net>
In-Reply-To: <BANLkTi=dPzu0wrDr3aycEv68M2tw7k5m8A@mail.gmail.com>

On Wed, May 11, 2011 at 12:40:27PM +0200, Sverre Rabbelier wrote:

> I just did 'git revert -p <commit>', hoping I might be able to
> partially revert a commit, but it just ignored the -p (it's not
> supported) rather than erroring out. Is this expected behavior?

Yeah, this is a problem with many commands that take revision parameters. The revision option parser will parse all of the log and diff options, modifying the rev_info struct, and then the resulting command may or may not do anything useful with the values. You can even do:

  git revert --pretty=oneline -p --date=iso --renames $sha1

all of which is equivalent to just:

  git revert $sha1

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. And I'm not even sure if that distinction is sufficient for all of the commands that use setup_revisions.

-Peff