Re: [PATCH 4/5] interpret-trailers: add an option to normalize output
- Date: Thu, 10 Aug 2017 23:06:40 +0200
- From: Christian Couder <christian.couder@xxxxxxxxx>
- Subject: Re: [PATCH 4/5] interpret-trailers: add an option to normalize output
On Thu, Aug 10, 2017 at 9:44 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote:
> On Thu, Aug 10, 2017 at 12:39 PM, Christian Couder
> <christian.couder@xxxxxxxxx> wrote:
>> On Thu, Aug 10, 2017 at 8:37 PM, Jeff King <peff@xxxxxxxx> 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@xxxxxxxx> 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
>>> 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, ...]
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
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.