Ævar Arnfjörð Bjarmason writes: > I started writing this on top of "master", but then saw the > outstanding series of other miscellaneous fixes to this > facility[1]. This is on top of that topic & rebased on master. > > Anders, any plans to re-roll yours? Otherwise the conflicts I'd have > on mine are easy to fix, so I can also submit it as a stand-alone. Yes, I have plans to do that. But have yet to carve out the required time from my copious spare time to actually do it. So please don't hold your breath waiting for me to do that. > This series comes out of a discussion at work today (well, yesterday > at this point) where someone wanted to parse %(trailers) output. As > noted in 3/5 doing this is rather tedious now if you're trying to > unambiguously grap trailers as a stream of key-value pairs. > > So this series adds a "key_value_separator" and "keyonly" parameters, > and fixes a few bugs I saw along the way. Interesting. When adding "valueonly" I never consider it being used without "key". The trick you are doing with separate keyonly and valueonly is quite clever. I've only been doing machine parsing for explicit keys, things like: "%cn%x00%x00%an%x00%x00%(trailers:key=Reviewed-By,valueonly,unfold,separator=%x00)%x00%x00%(trailers:key=Backport-Reviewed-By,valueonly,unfold,separator=%x00)" (double-NUL to separate field, single-NUL to separate values within field). But I can't help wonder that if the goal just is to have a nice machine parsable format maybe it would be easier (both for user and implementation) to have a separate placeholder for "machine readable trailers" which by default emits in a format suitable for machine parsing. Something like a new "%(ztrailers)" (but with a better name) which simply emits a sequence of "<KEY> NUL <VAL> NUL" for each trailer.
