* [RFC] Relaxing interpret-trailers' interpretation rules
@ 2019-08-20 2:13 Phil Hord
0 siblings, 0 replies; only message in thread
From: Phil Hord @ 2019-08-20 2:13 UTC (permalink / raw
To: Git; +Cc: Christian Couder
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.
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2019-08-20 2:14 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-08-20 2:13 [RFC] Relaxing interpret-trailers' interpretation rules Phil Hord
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.