Re: [PATCH 4/5] interpret-trailers: add an option to normalize output

[Christian Couder <christian.couder@gmail.com>]

On Thu, Aug 10, 2017 at 9:44 PM, Stefan Beller <sbeller@google.com> wrote:
> On Thu, Aug 10, 2017 at 12:39 PM, Christian Couder
> <christian.couder@gmail.com> wrote:
>> On Thu, Aug 10, 2017 at 8:37 PM, Jeff King <peff@peff.net> wrote:
>>> On Thu, Aug 10, 2017 at 11:35:00AM -0700, Stefan Beller wrote:
>>>
>>>> On Thu, Aug 10, 2017 at 1:03 AM, Jeff King <peff@peff.net> wrote:
>>>> > The point of "--only-trailers" is to give a caller an output
>>>> > that's easy for them to parse. Getting rid of the
>>>> > non-trailer material helps, but we still may see more
>>>> > complicated syntax like whitespace continuation. Let's add
>>>> > an option to normalize the output into one "key: value" line
>>>> > per trailer.
>>>> >
>>>> > As a bonus, this could be used even without --only-trailers
>>>> > to clean up unusual formatting in the incoming data.
>>>>
>>>> This is useful for the parsing part, but for the writing part we'd
>>>> rather want to have the opposite thing, such as
>>>> '--line-break=rfc822'. But this doesn't have to be part of this
>>>> series. With this in mind, I do not quite understand the latter
>>>> use case how you would use normalized trailers without
>>>> --only-trailers?
>>>
>>> If you prefer the normalized form (and the input was line-broken in a
>>> way that you don't like), then this would convert to your preferred
>>> form. I agree that you could potentially want the opposite (folding long
>>> lines). Perhaps something like --wrap=72.
>>
>> Related to this, I wonder if people might want to "normalize" in
>> different ways later. If that happens, we might regret having called
>> this option "--normalize" instead of "--one-per-line" for example.
>
> What is normal?
>
> Maybe --style=[one-line, wrapped:72, rfc, json, xml, ...]
> then?

Yeah, we could go there right now (using perhaps "--pretty" or
"--format" instead of "--style", so that we are more consistent with
other commands), but on the other hand we don't know yet if the other
formats will really be needed.

> If you have --one-per-line, this may be orthogonal to e.g. json
> (as json can be crammed into one line IIUC), but when given the
> selection you cannot combine multiple styles.
>
> Scratch that, we actually want to combine these styles with each
> other.

Yeah, that's another possibility for the future. People might want a
--json option that can be used both with and without --oneline. But as
the future is difficult to predict, let's try to make it easy for us
in both cases.

And I think starting with just "--oneline" would be easier to deal
with later than "--normalize" (or "--style" or "--pretty" or
"--format") especially in the latter case.