Derrick Stolee <derrickstolee@xxxxxxxxxx> writes:
>> git -c fetch.negotiationAlgorithm=noop fetch origin --no-tags --no-write-fetch-head --recurse-submodules=no --filter=blob:none --stdin
>>
>> Derrick told me to not depend on other flags like
>> `-c fetch.negotiationAlgorithm` etc. as they might be changed or omitted
>> and as it makes sense to me also. That's why I didn't specify those things.
>
> This reason is something that could be mentioned in the commit message
> to motivate the change to the helper.
>
>>> I wonder if it was more like this that the original wanted to grep for:
>>>
>>> grep '"event":"child_start".*\["git","pack-objects",.*\]'
>>
>> I don't know about other cases, but in my case, atleast I really wanted
>> it.
>>
>> So, In this scenerio, should I stick with `test_subcommand_inexact` or I
>> have to see other helper functions (or make my own) for it?
>
> As I mentioned earlier, it seems that
>
> test_subcommand_inexact ! git fetch
>
> would actually work for your needs without changing the helper. We will see
> whether or not the helper needs to be updated in a way that that line would
> not work anymore.
Ah, that is because the current implementation of the helper
sprinkles ".*" in between each and every pair of parameters, so the
resulting pattern \["git".*"fetch".*\] would not be prevented from
matching by the presence of "-c var.iable=value"?
In any case, the _inexact helper may need to be rethought, or at
least documented better what inexact-ness it wants to allow. With
no concrete goals written down, my guess was that it wanted to
ensure only the earlier command names and options, while ignoring
the later arguments. And that was where my "adding .* in between
looks wrong, and stripping trailing comma with ${expt%,} is nonsense"
comment came from.
Thanks.
