[PATCH v4 0/8] trailer parsing via interpret-trailers and %(trailers)

Here's a fourth version of my series to make the output of interpret-trailers useful for callers who just want to parse existing trailers.

The big change here is that I added similar features to pretty.c's "%(trailers)", meaning you can now efficiently get the same output for multiple commits with a single invocation. Like:

  $ git rev-list --no-walk --format='%(trailers:only:unfold)' \
    3ac53e0d13fa7483cce90eb6a1cfcdcbda5b8e35
  commit 3ac53e0d13fa7483cce90eb6a1cfcdcbda5b8e35
  Signed-off-by: H. Peter Anvin <hpa@zytor.com>
  Signed-off-by: Junio C Hamano <junkio@cox.net>

That doesn't look very exciting, but with just "%(trailers)" you would see that the block also contains a "cherry-picked from" line. There aren't good examples of unfolding in git.git because we don't tend to fold. Nor does linux.git (though they do have a lot of non-trailer lines in square brackets). The tests show off some samples of both.

I left %(trailers) exactly as it is: it shows the trailer block verbatim, including funny syntax, etc. As soon as you use one of :only or :unfold, we have to parse further, and as a side effect we normalize a few bits (like whitespace around separators), because we round-trip through the parser. I think that's fine and what callers would want. But it did make me wonder if I should just have a single "parse" option that does all that normalizing. Or alternatively, have %(trailers) always do that round-trip normalizing. That's how interpret-trailers behaves, after all(since it always parses and reconstructs the trailer block). I felt better taking the conservative route, though, and leaving %(trailers) alone.

There are a few other changes from v3:

  - the --normalize option is now --unfold (and I matched it with
    ":unfold" for the placeholder)

  - the process_input_file function now takes the
    process_trailer_options to check "only_trailers" instead of taking a
    hint from a NULL outfile. This is hopefully a bit more obvious.

  - when only_trailers is set, I don't even bother adding non-trailers
    from the middle of the trailer-block to the list (we know we'd never
    output them, and they can't affect the trailer rules). This is just
    a micro-optimization I noticed while writing the %(trailers) helper.

  - Similarly, we no longer unfold non-trailers. So if you have:

      key: value
        more value
      this is not a trailer
        this is also not a trailer

    we would unfold "key: value more value", but not the other two
    lines. Because without a separator, that's not really folding. I'm
    not sure it actually matters. It's hard to have non-trailers in the
    block in the first place. But I think the new behavior is the right
    thing if it ever does come up.

  [1/8]: trailer: put process_trailers() options into a struct
  [2/8]: interpret-trailers: add an option to show only the trailers
  [3/8]: interpret-trailers: add an option to show only existing trailers
  [4/8]: interpret-trailers: add an option to unfold values
  [5/8]: interpret-trailers: add --parse convenience option
  [6/8]: pretty: move trailer formatting to trailer.c
  [7/8]: t4205: refactor %(trailer) tests
  [8/8]: pretty: support normalization options for %(trailers)

 Documentation/git-interpret-trailers.txt |  33 +++++++--
 Documentation/pretty-formats.txt         |   5 +-
 builtin/interpret-trailers.c             |  34 +++++++--
 pretty.c                                 |  26 +++----
 t/t4205-log-pretty-formats.sh            |  51 ++++++++++++--
 t/t7513-interpret-trailers.sh            |  76 ++++++++++++++++++++
 trailer.c                                | 115 ++++++++++++++++++++++++++-----
 trailer.h                                |  27 +++++++-
 8 files changed, 315 insertions(+), 52 deletions(-)

-Peff