Re: [PATCH 0/5] make interpret-trailers useful for parsing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> writes:

> Parsing trailers out of a commit message is _mostly_ easy, but there
> area a lot of funny corner cases (e.g., heuristics for how many
> non-trailers must be present before a final paragraph isn't a trailer
> block anymore).  The code in trailer.c already knows about these corner
> cases, but there's no way to access it from the command line.
>
> This series teaches interpret-trailers to parse and output just the
> trailers. So now you can do:
>
>   $ git log --format=%B -1 8d44797cc91231cd44955279040dc4a1ee0a797f |
>     git interpret-trailers --parse
>   Signed-off-by: Hartmut Henkel <henkel@xxxxxxx>
>   Helped-by: Stefan Beller <sbeller@xxxxxxxxxx>
>   Signed-off-by: Ralf Thielow <ralf.thielow@xxxxxxxxx>
>   Acked-by: Matthias Rüster <matthias.ruester@xxxxxxxxx>

Thank-you, thank-you, thank-you.

The above example made me wonder if we also want a format specifier
to do the above without piping, but it turns out that we already
have "log --format=%(trailers)", so we are good ;-)

> I considered a few different approaches before deciding on
> what's here:
>
>   1. The output format is actually the normal "key: value" trailers. I
>      considered something more structured like JSON. But the "key:
>      value" format is quite easy to parse, once it has been normalized
>      (finding the trailers, unfolding whitespace continuation, etc).
>
>   2. This series introduces several orthogonal options which can be used
>      together to achieve my goal, when there could just be a "parse"
>      mode. Since interpret-trailers is plumbing, I reasoned that the
>      individual options might still be useful apart from each other (for
>      instance, you could re-normalize existing trailers while writing
>      your new ones from a commit hook). I did add a "--parse" for
>      convenience and to help point users in the right direction.
>
>      For the same reason (and so we could build on other orthogonal
>      features like --in-place and --trim-empty), I decided against
>      having a separate command like "git parse-trailers".
>
>   [1/5]: trailer: put process_trailers() options into a struct
>   [2/5]: interpret-trailers: add an option to show only the trailers
>   [3/5]: interpret-trailers: add an option to show only existing trailers
>   [4/5]: interpret-trailers: add an option to normalize output
>   [5/5]: interpret-trailers: add --parse convenience option
>
>  Documentation/git-interpret-trailers.txt | 17 ++++++++
>  builtin/interpret-trailers.c             | 34 ++++++++++++---
>  t/t7513-interpret-trailers.sh            | 73 ++++++++++++++++++++++++++++++++
>  trailer.c                                | 65 ++++++++++++++++++++++------
>  trailer.h                                | 12 +++++-
>  5 files changed, 180 insertions(+), 21 deletions(-)
>
> -Peff




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux