threads / rfc / 51688

[RFC] Relaxing interpret-trailers' interpretation rules

Subject: [RFC] Relaxing interpret-trailers' interpretation rules

## tl;dr

One message between Aug 20, 2019 and Aug 20, 2019.

replies: 0people: 1as markdown or json

Phil Hord· Aug 20, 2019, 02:13 UTC · lore

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.

← back to recent threads