>> 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.
> 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!
