Pierre Habouzit <madcoder@xxxxxxxxxx> writes:
> Okay this is kind of disgusting, and I'm absolutely not pleased with
> it (I mean I'm not pleased that parse_opt forces us to write things like
> that).
> ...
> I'll try to think harder about what we can do about it. Though for now,
> we will have to go for it for a while.
This is just a quick idea before I go back to sleep, but your earlier
comment on "--no-<an-option-that-is-not-even-boolean>" made me realize
that the alternative I was suggesting earlier would actually work much
nicer, if you introduce "--<an-option-that-take-optional-arg>-default"
magic.
Then, normal users who know what the value of $foo is (iow, not scripts)
can say:
git cmd --abbrev 10
git cmd --abbrev HEAD
git cmd --abbrev=10 HEAD
and scripts that want to have $foo to be treated as rev, even when it
consists entirely of digits, can say:
git cmd --abbrev-default $foo
to disambiguate (i.e. like "--no-" magic, "-default" is a magic, and it
tells the parser that "there is no option-argument given to this").
To make sure $foo is treated as the precision, the script can say:
git cmd --abbrev=$foo
If the script wants DWIM just like human users want, it can do:
git cmd --abbrev $foo
There of course is a little details called coding, but I think this is
probably the most user friendly to the users and the scripts alike. It
certainly is nicer than what the current parse_options() does, and/or
the git-tag workaround does.
-
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
