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 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
--
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]