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@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgpT2zthKNjgC.pgp
Description: PGP signature
