Re: [RFH] convert shortlog to use parse_options

On Thu, Dec 13, 2007 at 07:31:24PM +0000, Junio C Hamano wrote:

I understand that, and I hope I wasn't sounding harsh at all, I was just debating. Note that I don't like the asymmetry of some options needing a specific syntax whereas all the rest is lax. It's cumbersome at the very least. Though, to me there is one gain: when the user uses the --long-opt=foo version you are _sure_ about what he meant. When you have --long-opt foo you're not.

Your proposal tries hard to do what the user meant, with a reasonable
chance of being wrong. My proposal is on the conservative side, but
generate totally incomprehensible errors: if you do
  $ git describe --abbrev 10 HEAD
with my patch you get a not very nice
  fatal: Not a valid object name 10
as an answer. which is kind of going back to the kind of situations
parse-options is trying to avoid in the first place. I wouldn't be
really annoyed by my solution if we were able to generate an
intelligible error message instead. But guess what, if we were able to
do so, we would be able to fix the ambiguity in the first place *sigh*.

So maybe the thing would be to sleep on a it a bit and not taking any of my patches yet (not even in pu) and let people think. It's not a major problem, though it's one that must be fixed before 1.5.4 because we don't want a broken option parser ever be released.

Note that there is another path, that would be to disallow mixing of options with real arguments, and have an option separator (though with `--` having a distinct meaning in git, that wouldn't be that easy). But sadly some git commands already allowed such a thing, so imposing it in parse-options would be backward incompatible for those. And I believe many people are attached to this feature anyways.