Lucas Seiki Oshiro <lucasseikioshiro@xxxxxxxxx> writes:
>> Let's learn from our earlier mistakes and do it right in the
>> new incarnation.
>
> Ok, fair!
>
>> 1. In text mode, the values are shown one-item-per-line, even if
>> the value has embedded LF in it. At least we assume that the
>> values do not contain a NUL byte.
>>
>> 2. If a value does not have LF or double-quote in it, it is output
>> literally.
>>
>> 3. Otherwise, the value is shown with quote_c_style().
>
> Hmmm, ok. So, I if I understood it correctly, is your idea to keep
> the same functionality but using quote_c_style to keep one field
> per line?
I am not sure what you are comparing against with "the same" here,
but the idea is that not many items have problematic characters in
them anyway, and a simple-minded broken output parser can be written
in 5 minutes and would happen to work correctly in more than 80% of
repositories ;-) A production quality tool needs to be aware of the
possibility that they may need to unquote when they see a double-quote
at the beginning of a line.
By the way, somebody wondered in a nearby message why we do not have
the "key" and only "value" in the textual output, and I share the
same sentiment. Where JSON may say
"path": {
"git-dir": "/git/dir"
...
text format may want to say
path.git-dir=/git/dir
instead of just
/git/dir
But I dunno. When asking a single item from the command line, it is
perfectly fine to respond with a single value, but when you are
showing multiple items (especially without any "give me this and
that item and nothing else" specified on the command line, in which
case nobody knows in what order the value is given), I think the
calling script almost always wants to get key-value pairs.
Also are you planning on later adding a long-running server mode
like "cat-file --batch-command"?
