Re: [PATCH v4 5/9] parse-options: parse into strvec
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 6, 2020, 04:49 UTC
- Message-ID
- <xmqq362s6jrq.fsf@gitster.c.googlers.com>
- In-Reply-To
- <20201005233016.GC1393696@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
Show 26 quoted lines
> Emily Shaffer wrote:
>
>> This is useful if collecting generic arguments to pass through to
>> another command, for example, 'git hook run --arg "--quiet" --arg
>> "--format=pretty" some-hook'. The resulting strvec would contain
>> { "--quiet", "--format=pretty" }.
>
> An alternative is to use OPT_STRING_LIST and then convert in the
> caller. One advantage of that is that it would guarantee the behavior
> with --no-arg etc is going to match exactly.
>
> I prefer this OPT_STRVEC approach nonetheless. Can the
> parse_opt_strvec and parse_opt_string_list functions get comments
> pointing to each other as an alternative way to encourage that kind of
> consistency?
>
> [...]
>> --- a/Documentation/technical/api-parse-options.txt
>> +++ b/Documentation/technical/api-parse-options.txt
>> @@ -173,6 +173,11 @@ There are some macros to easily define options:
>> The string argument is stored as an element in `string_list`.
>> Use of `--no-option` will clear the list of preceding values.
>>
>> +`OPT_ARGV_ARRAY(short, long, &struct argv_array, arg_str, description)`::
>
> nit: this should be OPT_STRVECSigh. I thought I caught all of these with a SQUASH fix-up patch the last round. Thanks for being extra careful.