{"thread":{"id":"44511","subject":"[PATCH 1/2] pretty: add %bT format for displaying trailers of a commit message","startedAt":"2016-11-18T23:08:44Z","lastAt":"2016-11-29T18:43:38Z","messageCount":9,"participants":["Jacob Keller","Junio C Hamano","Jonathan Tan","Keller, Jacob E"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"306178","messageId":"20161118230825.20952-2-jacob.e.keller@intel.com","threadId":"44511","inReplyTo":"20161118230825.20952-1-jacob.e.keller@intel.com","subject":"[PATCH 1/2] pretty: add %bT format for displaying trailers of a commit message","fromName":"Jacob Keller","fromEmail":"jacob.e.keller@intel.com","sentAt":"2016-11-18T23:08:24Z","receivedAt":"2016-11-18T23:08:44Z","isPatch":true,"sender":{"key":"jacob.e.keller@intel.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"From: Jacob Keller <jacob.keller@gmail.com>\n\nRecent patches have expanded on the trailers.c code and we have the\nbuiltin commant git-interpret-trailers which can be used to add or\nmodify trailer lines. However, there is no easy way to simply display\nthe trailers of a commit message. Add support for %bT format modifier\nwhich will use the trailer_info_get() calls to read trailers in an\nidentical way as git interpret-trailers does.\n\nAdd documentation and tests for the same.\n\nSigned-off-by: Jacob Keller <jacob.keller@gmail.com>\n---\n Documentation/pretty-formats.txt |  1 +\n pretty.c                         | 18 ++++++++++++++++++\n t/t4205-log-pretty-formats.sh    | 26 ++++++++++++++++++++++++++\n 3 files changed, 45 insertions(+)\n\ndiff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt\nindex 3bcee2ddb124..9ee68a4cb64a 100644\n--- a/Documentation/pretty-formats.txt\n+++ b/Documentation/pretty-formats.txt\n@@ -138,6 +138,7 @@ The placeholders are:\n - '%s': subject\n - '%f': sanitized subject line, suitable for a filename\n - '%b': body\n+- '%bT': trailers of body as interpreted by linkgit:git-interpret-trailers[1]\n - '%B': raw body (unwrapped subject and body)\n ifndef::git-rev-list[]\n - '%N': commit notes\ndiff --git a/pretty.c b/pretty.c\nindex 37b2c3b1f995..ea8764334865 100644\n--- a/pretty.c\n+++ b/pretty.c\n@@ -10,6 +10,7 @@\n #include \"color.h\"\n #include \"reflog-walk.h\"\n #include \"gpg-interface.h\"\n+#include \"trailer.h\"\n \n static char *user_format;\n static struct cmt_fmt_map {\n@@ -889,6 +890,16 @@ const char *format_subject(struct strbuf *sb, const char *msg,\n \treturn msg;\n }\n \n+static void format_trailers(struct strbuf *sb, const char *msg)\n+{\n+\tstruct trailer_info info;\n+\n+\ttrailer_info_get(&info, msg);\n+\tstrbuf_add(sb, info.trailer_start,\n+\t\t   info.trailer_end - info.trailer_start);\n+\ttrailer_info_release(&info);\n+}\n+\n static void parse_commit_message(struct format_commit_context *c)\n {\n \tconst char *msg = c->message + c->message_off;\n@@ -1289,6 +1300,13 @@ static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */\n \t\tformat_sanitized_subject(sb, msg + c->subject_off);\n \t\treturn 1;\n \tcase 'b':\t/* body */\n+\t\tswitch (placeholder[1]) {\n+\t\tcase 'T':\n+\t\t\tformat_trailers(sb, msg + c->subject_off);\n+\t\t\treturn 2;\n+\t\tdefault:\n+\t\t\tbreak;\n+\t\t}\n \t\tstrbuf_addstr(sb, msg + c->body_off);\n \t\treturn 1;\n \t}\ndiff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh\nindex f5435fd250ba..7a35941ddcbd 100755\n--- a/t/t4205-log-pretty-formats.sh\n+++ b/t/t4205-log-pretty-formats.sh\n@@ -535,4 +535,30 @@ test_expect_success 'clean log decoration' '\n \ttest_cmp expected actual1\n '\n \n+cat >trailers <<EOF\n+Signed-off-by: A U Thor <author@example.com>\n+Acked-by: A U Thor <author@example.com>\n+[ v2 updated patch description ]\n+Signed-off-by: A U Thor <author@example.com>\n+EOF\n+\n+test_expect_success 'pretty format %bT shows trailers' '\n+\techo \"Some contents\" >trailerfile &&\n+\tgit add trailerfile &&\n+\tgit commit -F - <<-EOF &&\n+\ttrailers: this commit message has trailers\n+\n+\tThis commit is a test commit with trailers at the end. We parse this\n+\tmessage and display the trailers using %bT\n+\n+\t$(cat trailers)\n+\tEOF\n+\tgit log --no-walk --pretty=\"%bT\" >actual &&\n+\tcat >expect <<-EOF &&\n+\t$(cat trailers)\n+\n+\tEOF\n+\ttest_cmp expect actual\n+'\n+\n test_done\n-- \n2.11.0.rc2.152.g4d04e67\n\n"},{"id":"306179","messageId":"20161118230825.20952-3-jacob.e.keller@intel.com","threadId":"44511","inReplyTo":"20161118230825.20952-1-jacob.e.keller@intel.com","subject":"[PATCH 2/2] ref-filter: add support to display trailers as part of contents","fromName":"Jacob Keller","fromEmail":"jacob.e.keller@intel.com","sentAt":"2016-11-18T23:08:25Z","receivedAt":"2016-11-18T23:08:48Z","isPatch":true,"sender":{"key":"jacob.e.keller@intel.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"From: Jacob Keller <jacob.keller@gmail.com>\n\nAdd %(trailers) and %(contents:trailers) to display the trailers as\ninterpreted by trailer_info_get. Update documentation and add a test for\nthe new feature.\n\nSigned-off-by: Jacob Keller <jacob.keller@gmail.com>\n---\n Documentation/git-for-each-ref.txt |  2 ++\n ref-filter.c                       | 22 +++++++++++++++++++++-\n t/t6300-for-each-ref.sh            | 26 ++++++++++++++++++++++++++\n 3 files changed, 49 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt\nindex f57e69bc83e3..e5807eede787 100644\n--- a/Documentation/git-for-each-ref.txt\n+++ b/Documentation/git-for-each-ref.txt\n@@ -165,6 +165,8 @@ of all lines of the commit message up to the first blank line.  The next\n line is 'contents:body', where body is all of the lines after the first\n blank line.  The optional GPG signature is `contents:signature`.  The\n first `N` lines of the message is obtained using `contents:lines=N`.\n+Additionally, the trailers as interpreted by linkgit:git-interpret-trailers[1]\n+are obtained as 'contents:trailers'.\n \n For sorting purposes, fields with numeric values sort in numeric order\n (`objectsize`, `authordate`, `committerdate`, `creatordate`, `taggerdate`).\ndiff --git a/ref-filter.c b/ref-filter.c\nindex d4c2931f3aab..b6f1bb73ed37 100644\n--- a/ref-filter.c\n+++ b/ref-filter.c\n@@ -13,6 +13,7 @@\n #include \"utf8.h\"\n #include \"git-compat-util.h\"\n #include \"version.h\"\n+#include \"trailer.h\"\n \n typedef enum { FIELD_STR, FIELD_ULONG, FIELD_TIME } cmp_type;\n \n@@ -40,7 +41,7 @@ static struct used_atom {\n \t\tenum { RR_NORMAL, RR_SHORTEN, RR_TRACK, RR_TRACKSHORT }\n \t\t\tremote_ref;\n \t\tstruct {\n-\t\t\tenum { C_BARE, C_BODY, C_BODY_DEP, C_LINES, C_SIG, C_SUB } option;\n+\t\t\tenum { C_BARE, C_BODY, C_BODY_DEP, C_LINES, C_SIG, C_SUB, C_TRAILERS } option;\n \t\t\tunsigned int nlines;\n \t\t} contents;\n \t\tenum { O_FULL, O_SHORT } objectname;\n@@ -85,6 +86,13 @@ static void subject_atom_parser(struct used_atom *atom, const char *arg)\n \tatom->u.contents.option = C_SUB;\n }\n \n+static void trailers_atom_parser(struct used_atom *atom, const char *arg)\n+{\n+\tif (arg)\n+\t\tdie(_(\"%%(trailers) does not take arguments\"));\n+\tatom->u.contents.option = C_TRAILERS;\n+}\n+\n static void contents_atom_parser(struct used_atom *atom, const char *arg)\n {\n \tif (!arg)\n@@ -95,6 +103,8 @@ static void contents_atom_parser(struct used_atom *atom, const char *arg)\n \t\tatom->u.contents.option = C_SIG;\n \telse if (!strcmp(arg, \"subject\"))\n \t\tatom->u.contents.option = C_SUB;\n+\telse if (!strcmp(arg, \"trailers\"))\n+\t\tatom->u.contents.option = C_TRAILERS;\n \telse if (skip_prefix(arg, \"lines=\", &arg)) {\n \t\tatom->u.contents.option = C_LINES;\n \t\tif (strtoul_ui(arg, 10, &atom->u.contents.nlines))\n@@ -194,6 +204,7 @@ static struct {\n \t{ \"creatordate\", FIELD_TIME },\n \t{ \"subject\", FIELD_STR, subject_atom_parser },\n \t{ \"body\", FIELD_STR, body_atom_parser },\n+\t{ \"trailers\", FIELD_STR, trailers_atom_parser },\n \t{ \"contents\", FIELD_STR, contents_atom_parser },\n \t{ \"upstream\", FIELD_STR, remote_ref_atom_parser },\n \t{ \"push\", FIELD_STR, remote_ref_atom_parser },\n@@ -785,6 +796,7 @@ static void grab_sub_body_contents(struct atom_value *val, int deref, struct obj\n \t\t\tname++;\n \t\tif (strcmp(name, \"subject\") &&\n \t\t    strcmp(name, \"body\") &&\n+\t\t    strcmp(name, \"trailers\") &&\n \t\t    !starts_with(name, \"contents\"))\n \t\t\tcontinue;\n \t\tif (!subpos)\n@@ -808,6 +820,14 @@ static void grab_sub_body_contents(struct atom_value *val, int deref, struct obj\n \t\t\t/*  Size is the length of the message after removing the signature */\n \t\t\tappend_lines(&s, subpos, contents_end - subpos, atom->u.contents.nlines);\n \t\t\tv->s = strbuf_detach(&s, NULL);\n+\t\t} else if (atom->u.contents.option == C_TRAILERS) {\n+\t\t\tstruct trailer_info info;\n+\n+\t\t\t/* Search for trailer info */\n+\t\t\ttrailer_info_get(&info, subpos);\n+\t\t\tv->s = xmemdupz(info.trailer_start,\n+\t\t\t\t\tinfo.trailer_end - info.trailer_start);\n+\t\t\ttrailer_info_release(&info);\n \t\t} else if (atom->u.contents.option == C_BARE)\n \t\t\tv->s = xstrdup(subpos);\n \t}\ndiff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh\nindex 19a2823025e7..eb4bac0fe477 100755\n--- a/t/t6300-for-each-ref.sh\n+++ b/t/t6300-for-each-ref.sh\n@@ -553,4 +553,30 @@ test_expect_success 'Verify sort with multiple keys' '\n \t\trefs/tags/bogo refs/tags/master > actual &&\n \ttest_cmp expected actual\n '\n+\n+cat >trailers <<EOF\n+Reviewed-by: A U Thor <author@example.com>\n+Signed-off-by: A U Thor <author@example.com>\n+EOF\n+\n+test_expect_success 'basic atom: head contents:trailers' '\n+\techo \"Some contents\" > two &&\n+\tgit add two &&\n+\tgit commit -F - <<-EOF &&\n+\ttrailers: this commit message has trailers\n+\n+\tSome message contents\n+\n+\t$(cat trailers)\n+\tEOF\n+\tgit for-each-ref --format=\"%(contents:trailers)\" refs/heads/master >actual &&\n+\tsanitize_pgp <actual >actual.clean &&\n+\t# git for-each-ref ends with a blank line\n+\tcat >expect <<-EOF &&\n+\t$(cat trailers)\n+\n+\tEOF\n+\ttest_cmp expect actual.clean\n+'\n+\n test_done\n-- \n2.11.0.rc2.152.g4d04e67\n\n"},{"id":"306180","messageId":"20161118230825.20952-1-jacob.e.keller@intel.com","threadId":"44511","inReplyTo":null,"subject":"[PATCH 0/2] add format specifiers to display trailers","fromName":"Jacob Keller","fromEmail":"jacob.e.keller@intel.com","sentAt":"2016-11-18T23:08:23Z","receivedAt":"2016-11-18T23:08:49Z","isPatch":true,"sender":{"key":"jacob.e.keller@intel.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"From: Jacob Keller <jacob.keller@gmail.com>\n\nThis is based off of jt/use-trailer-api-in-commands so that we can make\nuse of the public trailer API that will parse a string for trailers.\n\nI use trailers as a way to store extra commit metadata, and would like a\nconvenient way to obtain the trailers of a commit message easily. This\nadds format specifiers to both the ref-filter API and the pretty\nformats. I am not a fan of %bT but %t and %T were already taken. I don't\nreally know if it's ok to use %bT, since I think we used to allow \"%bT\"\nformat, though i don't think this is likely used much in practice.\n\nI am open to suggestions for the pretty format specifier.\n\nAdditionally, I am somewhat not a fan of the way that if you have a\nseries of trailers which are trailer format, but not recognized, such\nas the following:\n\n<text>\n\nMy-tag: my value\nMy-other-tag: my other value\n[non-trailer line]\nMy-tag: my third value\n\n---\n\nGit interpret-trailers will not recognize this as a trailer block\nbecause it doesn't have any standard git tags within it. Would it be ok\nto augment the trailer interpretation to say that if we have over 75%\ntrailers in the block that we accept it even if it doesn't have any real\nrecognized tags?\n\nI say this because I regularly use extra tags in my git projects to\nrepresent change metadata, and it would be nice if the tag block could\nbe recognized even if it has 1-2 lines of non-trailer formatting in\nit...\n\nThoughts?\n\nJacob Keller (2):\n  pretty: add %bT format for displaying trailers of a commit message\n  ref-filter: add support to display trailers as part of contents\n\n Documentation/git-for-each-ref.txt |  2 ++\n Documentation/pretty-formats.txt   |  1 +\n pretty.c                           | 18 ++++++++++++++++++\n ref-filter.c                       | 22 +++++++++++++++++++++-\n t/t4205-log-pretty-formats.sh      | 26 ++++++++++++++++++++++++++\n t/t6300-for-each-ref.sh            | 26 ++++++++++++++++++++++++++\n 6 files changed, 94 insertions(+), 1 deletion(-)\n\n-- \n2.11.0.rc2.152.g4d04e67\n\n"},{"id":"306183","messageId":"xmqq8tsgl5o4.fsf@gitster.mtv.corp.google.com","threadId":"44511","inReplyTo":"20161118230825.20952-1-jacob.e.keller@intel.com","subject":"Re: [PATCH 0/2] add format specifiers to display trailers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-11-18T23:38:51Z","receivedAt":"2016-11-18T23:38:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jacob Keller <jacob.e.keller@intel.com> writes:\n\n> Git interpret-trailers will not recognize this as a trailer block\n> because it doesn't have any standard git tags within it. Would it be ok\n> to augment the trailer interpretation to say that if we have over 75%\n> trailers in the block that we accept it even if it doesn't have any real\n> recognized tags?\n\nI thought the documented way to do this is to configure one of your\ncustom trailer as such.  Jonathan?\n\n>   pretty: add %bT format for displaying trailers of a commit message\n\nAre %(...) taken already?  In longer term, it would be nice if we\ncan unify the --pretty formats and for-each-ref formats, so it is\nprobably better if we avoid adding any new short ones to the former.\n\nWe have %s and %b so that we can reconstruct the whole thing by\nusing both.  It is unclear how %bT fits in this picture.  I wonder\nif we also need another placeholder that expands to the body of the\nmessage without the trailer---otherwise the whole set would become\nincoherent, no?\n\n"},{"id":"306186","messageId":"CA+P7+xrQEBYQQhqJQQCpLrs+4WOJOvH1X27w5Ou=2VPT=FegGQ@mail.gmail.com","threadId":"44511","inReplyTo":"xmqq8tsgl5o4.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 0/2] add format specifiers to display trailers","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-11-18T23:42:52Z","receivedAt":"2016-11-18T23:43:19Z","isPatch":true,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Fri, Nov 18, 2016 at 3:38 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Jacob Keller <jacob.e.keller@intel.com> writes:\n>\n>> Git interpret-trailers will not recognize this as a trailer block\n>> because it doesn't have any standard git tags within it. Would it be ok\n>> to augment the trailer interpretation to say that if we have over 75%\n>> trailers in the block that we accept it even if it doesn't have any real\n>> recognized tags?\n>\n> I thought the documented way to do this is to configure one of your\n> custom trailer as such.  Jonathan?\n>\n\nThat would be fine then, if that works.\n\n>>   pretty: add %bT format for displaying trailers of a commit message\n>\n> Are %(...) taken already?  In longer term, it would be nice if we\n> can unify the --pretty formats and for-each-ref formats, so it is\n> probably better if we avoid adding any new short ones to the former.\n>\n\nOh, I hadn't considered adding a longer one. I'll rework this to use\nlonger ones.\n\n> We have %s and %b so that we can reconstruct the whole thing by\n> using both.  It is unclear how %bT fits in this picture.  I wonder\n> if we also need another placeholder that expands to the body of the\n> message without the trailer---otherwise the whole set would become\n> incoherent, no?\n>\n\nI'm not entirely sure what to do here. I just wanted a way to easily\nformat \"just the trailers\" of a message. We could add something that\nformats just the non-trailers, that's not too difficult. Not really\nsure what I'd call it though.\n\nThanks,\nJake\n"},{"id":"306222","messageId":"xmqqwpfwkar2.fsf@gitster.mtv.corp.google.com","threadId":"44511","inReplyTo":"CA+P7+xrQEBYQQhqJQQCpLrs+4WOJOvH1X27w5Ou=2VPT=FegGQ@mail.gmail.com","subject":"Re: [PATCH 0/2] add format specifiers to display trailers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-11-21T17:23:29Z","receivedAt":"2016-11-21T17:23:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jacob Keller <jacob.keller@gmail.com> writes:\n\n>> We have %s and %b so that we can reconstruct the whole thing by\n>> using both.  It is unclear how %bT fits in this picture.  I wonder\n>> if we also need another placeholder that expands to the body of the\n>> message without the trailer---otherwise the whole set would become\n>> incoherent, no?\n>\n> I'm not entirely sure what to do here. I just wanted a way to easily\n> format \"just the trailers\" of a message. We could add something that\n> formats just the non-trailers, that's not too difficult. Not really\n> sure what I'd call it though.\n\nI was wondering if %(log:<name of a part>) was a better way to go.\n\n%(log:title) and %(log:body) would be equivalents of traditional %s\nand %b, and %(log:body) in turn would be a shorter way to write\n%(log:description)%+(log:trailer), i.e. show the message body, and\nif there is a trailer block, add it after adding a blank line.\n\nOr something like that?\n"},{"id":"306247","messageId":"1479761241-26284-1-git-send-email-jonathantanmy@google.com","threadId":"44511","inReplyTo":"CA+P7+xrQEBYQQhqJQQCpLrs+4WOJOvH1X27w5Ou=2VPT=FegGQ@mail.gmail.com","subject":"[PATCH] doc: mention user-configured trailers","fromName":"Jonathan Tan","fromEmail":"jonathantanmy@google.com","sentAt":"2016-11-21T20:47:21Z","receivedAt":"2016-11-21T20:47:35Z","isPatch":true,"sender":{"key":"jonathantanmy@fastmail.com","avatar":null},"body":"In commit 1462450 (\"trailer: allow non-trailers in trailer block\",\n2016-10-21), functionality was added (and tested [1]) to allow\nnon-trailer lines in trailer blocks, as long as those blocks contain at\nleast one Git-generated or user-configured trailer, and consists of at\nleast 25% trailers. The documentation was updated to mention this new\nfunctionality, but did not mention \"user-configured trailer\".\n\nFurther update the documentation to also mention \"user-configured\ntrailer\".\n\n[1] \"with non-trailer lines mixed with a configured trailer\" in\nt/t7513-interpret-trailers.sh\n\nSigned-off-by: Jonathan Tan <jonathantanmy@google.com>\n---\n\nYes, mentioning a trailer in a Git config will cause interpret-trailers\nto treat it similarly to a Git-generated trailer (in that its presence\ncauses a block partially consisting of trailers to be considered a\ntrailer block). See the commit message above for a test case that\nverifies that.\n\nI took a look at the documentation, and it wasn't completely documented,\nso here is a patch to correct that.\n\n Documentation/git-interpret-trailers.txt | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-interpret-trailers.txt b/Documentation/git-interpret-trailers.txt\nindex e99bda6..09074c7 100644\n--- a/Documentation/git-interpret-trailers.txt\n+++ b/Documentation/git-interpret-trailers.txt\n@@ -49,7 +49,8 @@ will be added before the new trailer.\n \n Existing trailers are extracted from the input message by looking for\n a group of one or more lines that (i) are all trailers, or (ii) contains at\n-least one Git-generated trailer and consists of at least 25% trailers.\n+least one Git-generated or user-configured trailer and consists of at\n+least 25% trailers.\n The group must be preceded by one or more empty (or whitespace-only) lines.\n The group must either be at the end of the message or be the last\n non-whitespace lines before a line that starts with '---'. Such three\n-- \n2.8.0.rc3.226.g39d4020\n\n"},{"id":"306254","messageId":"xmqqtwb0h6jw.fsf@gitster.mtv.corp.google.com","threadId":"44511","inReplyTo":"1479761241-26284-1-git-send-email-jonathantanmy@google.com","subject":"Re: [PATCH] doc: mention user-configured trailers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-11-21T21:22:27Z","receivedAt":"2016-11-21T21:22:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Tan <jonathantanmy@google.com> writes:\n\n> In commit 1462450 (\"trailer: allow non-trailers in trailer block\",\n> 2016-10-21), functionality was added (and tested [1]) to allow\n> non-trailer lines in trailer blocks, as long as those blocks contain at\n> least one Git-generated or user-configured trailer, and consists of at\n> least 25% trailers. The documentation was updated to mention this new\n> functionality, but did not mention \"user-configured trailer\".\n>\n> Further update the documentation to also mention \"user-configured\n> trailer\".\n>\n> [1] \"with non-trailer lines mixed with a configured trailer\" in\n> t/t7513-interpret-trailers.sh\n>\n> Signed-off-by: Jonathan Tan <jonathantanmy@google.com>\n> ---\n>\n> Yes, mentioning a trailer in a Git config will cause interpret-trailers\n> to treat it similarly to a Git-generated trailer (in that its presence\n> causes a block partially consisting of trailers to be considered a\n> trailer block). See the commit message above for a test case that\n> verifies that.\n>\n> I took a look at the documentation, and it wasn't completely documented,\n> so here is a patch to correct that.\n\nLooks sensible. Thanks.\n\n>  Documentation/git-interpret-trailers.txt | 3 ++-\n>  1 file changed, 2 insertions(+), 1 deletion(-)\n>\n> diff --git a/Documentation/git-interpret-trailers.txt b/Documentation/git-interpret-trailers.txt\n> index e99bda6..09074c7 100644\n> --- a/Documentation/git-interpret-trailers.txt\n> +++ b/Documentation/git-interpret-trailers.txt\n> @@ -49,7 +49,8 @@ will be added before the new trailer.\n>  \n>  Existing trailers are extracted from the input message by looking for\n>  a group of one or more lines that (i) are all trailers, or (ii) contains at\n> -least one Git-generated trailer and consists of at least 25% trailers.\n> +least one Git-generated or user-configured trailer and consists of at\n> +least 25% trailers.\n>  The group must be preceded by one or more empty (or whitespace-only) lines.\n>  The group must either be at the end of the message or be the last\n>  non-whitespace lines before a line that starts with '---'. Such three\n"},{"id":"306554","messageId":"1480444993.3154.3.camel@intel.com","threadId":"44511","inReplyTo":"xmqqwpfwkar2.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 0/2] add format specifiers to display trailers","fromName":"Keller, Jacob E","fromEmail":"jacob.e.keller@intel.com","sentAt":"2016-11-29T18:43:15Z","receivedAt":"2016-11-29T18:43:38Z","isPatch":true,"sender":{"key":"jacob.e.keller@intel.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Mon, 2016-11-21 at 09:23 -0800, Junio C Hamano wrote:\n> Jacob Keller <jacob.keller@gmail.com> writes:\n> \n> > > We have %s and %b so that we can reconstruct the whole thing by\n> > > using both.  It is unclear how %bT fits in this picture.  I\n> > > wonder\n> > > if we also need another placeholder that expands to the body of\n> > > the\n> > > message without the trailer---otherwise the whole set would\n> > > become\n> > > incoherent, no?\n> > \n> > I'm not entirely sure what to do here. I just wanted a way to\n> > easily\n> > format \"just the trailers\" of a message. We could add something\n> > that\n> > formats just the non-trailers, that's not too difficult. Not really\n> > sure what I'd call it though.\n> \n> I was wondering if %(log:<name of a part>) was a better way to go.\n> \n> %(log:title) and %(log:body) would be equivalents of traditional %s\n> and %b, and %(log:body) in turn would be a shorter way to write\n> %(log:description)%+(log:trailer), i.e. show the message body, and\n> if there is a trailer block, add it after adding a blank line.\n> \n> Or something like that?\n\nThat would work for me.\n\nThanks,\nJake"}]}