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