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