Re: [PATCH v2] t/perf/run: Use proper "--get-regexp", not "--get-regex"
- Date: Mon, 4 Jun 2018 07:03:25 -0400 (EDT)
- From: "Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx>
- Subject: Re: [PATCH v2] t/perf/run: Use proper "--get-regexp", not "--get-regex"
On Sun, 3 Jun 2018, Philip Oakley wrote:
> From: "Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx>
> > On Sun, 3 Jun 2018, Thomas Gummerer wrote:
> >> --get-regex works as the parse-option API allows abbreviations of
> >> the full option to be specified as long as the abbreviation is
> >> unambiguos. I don't know if this is documented anywhere other
> >> than 'Documentation/technical/api-parse-options.txt' though.
> it's in `git help cli`:
> many commands allow a long option --option to be abbreviated only to
> their unique prefix (e.g. if there is no other option whose name
> begins with opt, you may be able to spell --opt to invoke the
> --option flag), but you should fully spell them out when writing
> your scripts;
> It's a worthwile read, even if the man page isn't flagged up that
agreed that it's a good read and should be referenced more often.
one thing i don't see there, and it's based on an observation someone
once made (i believe on this list), is that even if there is
absolutely no ambiguity in a command, even if there are no pathspec
arguments, it's still worthwhile to add a trailing "--":
$ git command options/treeish ... --
since that guarantees that git will waste no time trying to identify
any ambiguity since you're being so precise. is that worth mentioning
in that page?
Robert P. J. Day Ottawa, Ontario, CANADA