Pierre Habouzit <madcoder@xxxxxxxxxx> writes:
> In fact we have kind of the issue for every single optional argument out
> there:
>
> $ git describe --abbrev HEAD
> error: option `abbrev' expects a numerical value
> [...]
>
> *ouch*
>
> So I believe that with optional arguments we must change the way we do
> things, and that we _must_ enforce the argument to be sticked in that
> case.
I think "Must" is a bit too strong an expression.
git describe --abbrev 7 HEAD
git describe --abbrev HEAD
git describe --abbrev=HEAD
git describe --abbrev=7 HEAD
git describe --abbrev
The --abbrev parser in this case could be asked with this question: "You
are on the command line. There is a token after you. Is it your
parameter?".
Among the above cases, the third one through the last one will get slightly
different questions. The third and fourth ones get "You are given this
parameter and it must be yours", and the last one gets "You are on the
command line, and were not given any parameter."
The parser can do one of these things:
* Inspect the token, if exists, and see if it is appropriate for it.
* If not
- if it is optional, then take the default value, and answer "I
handled myself Ok, but that HEAD is not mine";
- if it "must be yours" (the third case), barf.
* If so
- Use that given value and answer "I handled myself Ok, and that
parameter 7 is mine"; this includes the fourth case as well.
And this does not have to be callback for common types like integers.
-
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
