[RFC] Relaxing interpret-trailers' interpretation rules

From: Phil Hord <hidden>
Date: 2019-08-20 02:14:15

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help