# [RFC] Relaxing interpret-trailers' interpretation rules

1 messages from 2019-08-20 to 2019-08-20. Participants: Phil Hord.
Thread: https://gitlist.dev/t/51688

## Phil Hord, 2019-08-20 02:13

Subject: [RFC] Relaxing interpret-trailers' interpretation rules
Message-ID: <CABURp0r2sn7LUYFNegLVx5G+zZXpiPz2YdmKfG1EDHkXf61E+Q@mail.gmail.com>
URL: https://gitlist.dev/e/CABURp0r2sn7LUYFNegLVx5G%2BzZXpiPz2YdmKfG1EDHkXf61E%2BQ%40mail.gmail.com

```
I'm trying to include "Bug" numbers from commit messages in my
one-line log output, like this:
git log --pretty="%h %(trailers:key=Bug,valueonly,separator=;) %s"

But I have a problem.  We have a tool that appends a trailer to commit
messages like this:

   Reviewed at https://reviews.myco.com/012345

Unfortunately, it adds a newline before this line, effectively making
'git interpret-trailers' think there are no other trailers.

    foo: add new feature foo

    yadda yadda yadda

    Bug: PROJ-155485
    Testing: https://jenkins/job/foo-functional/1/console

    Reviewed at https://reviews.myco.com/012345

I could fix this going forward, but it doesn't help with my existing
project and various users' similar formats.

I'm thinking of adding a switch to interpret-trailers to tell it not
to stop searching for my trailer key at the last blank line in the
message.  This feels like it will cheapen the purpose of
interpret-trailers, though.

Do you have thoughts on this idea?

Another option I considered is adding some extension to --pretty's
format to let me post-process fields in a command.  I don't think such
a thing already exists, but with the myriad log formats available,
maybe I've overlooked something.

```