Re: [RFH] convert shortlog to use parse_options

[Pierre Habouzit <madcoder@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 2351 bytes --]

On Thu, Dec 13, 2007 at 07:31:24PM +0000, Junio C Hamano wrote:
> So I am not entirely opposed to your version, nor I am claiming my
> suggestion is better.  However, I just thought that "some parameters you
> MUST stick to the flag" might create confusion to the end users, and I
> wanted to see if others can come up with a less confusing alternative.
> And the way I did so was to keep the discussion going by stirring the
> pot a bit.

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.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]