Lucas Seiki Oshiro <lucasseikioshiro@xxxxxxxxx> writes:
>>> Also add a flag --allow-empty, which will force the output data to be
>>> empty when no field is requested.
>>>
>> Why do you suppose we need this, I'm not against it, but it would be
>> nice to state why this is necessary. The idea is to have a default
>> output when a user runs `git repo-info`, so I'm missing why this would
>> be useful.
>
> I was thinking about use cases where repo-info is used inside scripts.
> A simple (but kinda useless...) example: an application that is a GUI
> for this command, where the fields are selected in a checkbox, calling
> repo-info with them and then displaying their contents in a dialog.
>
> In this example, if no field is selected and there's no validation in
> the GUI side, the default set of data will be retrieved. With
> git repo-info --allow-empty, we don't need to care about it.
>
> But, yeah, I agree that we don't need to think about it by now...
>
>> If I recall correctly, in our previous internal review, it was mentioned
>> that since we use perl here, we should add a PERL pre-requisite. Similar
>> to the one in 't/t0019-json-writer.sh'.
>
> Do you mean to use a `test_lazy_prereq`? I'll take a look on that.
>
Yes, that's the one.
>> As of this patch,
>>
>> $ ~/code/git/build/bin-wrappers/git repo-info
>> {
>> }
>>
>> $ ~/code/git/build/bin-wrappers/git repo-info --allow-empty
>> {
>> }
>>
>> So what differentiates the former from the latter?
>
> In this patch, nothing. I was only trying to keep the consistency
> of each patch from 3 to 5 implementing only the code related to the
> field, but it seems ok to me to squash this patch and the next one.
>
>> This is because we didn't implement plainttext no?
>
> Yes!
Attachment:
signature.asc
Description: PGP signature
