Jeff King <peff@xxxxxxxx> writes: > On Fri, Aug 18, 2017 at 02:26:14PM -0700, Junio C Hamano wrote: > >> * jk/trailers-parse (2017-08-15) 8 commits >> - pretty: support normalization options for %(trailers) >> - t4205: refactor %(trailers) tests >> - pretty: move trailer formatting to trailer.c >> - interpret-trailers: add --parse convenience option >> - interpret-trailers: add an option to unfold values >> - interpret-trailers: add an option to show only existing trailers >> - interpret-trailers: add an option to show only the trailers >> - trailer: put process_trailers() options into a struct >> >> "git interpret-trailers" has been taught a "--parse" and a few >> other options to make it easier for scripts to grab existing >> trailer lines from a commit log message. >> >> Will merge to 'next'. > > I saw that this was merged and ended up with a few conflicts related to > the other interpret-trailers series (sorry). Your resolution looks good > to me. Thanks for double checking. This was an easy conflict--the only remotely tricky part was "list.nr -> !list_empty(&list)". > There are a few leftover bits I think we could do on top: > > - we disallow "--trailer" with "--only-input", because the former is > quietly ignored. After the two series are merged, I think "--where", > etc should probably get the same treatment (the behavior without it > isn't horrible, but it's nice to warn the user that what they asked > for is bogus). Sounds good. I didn't think about that case. The implementation would have to add another variable whose sole purpose is to keep track of "have we ever seen any of these options?" and flip it in the callbacks that implement these options, as there is no way to tell between WHERE_DEFAULT that is set from the command line, from the configuration, or left as-is without either. > - Martin pointed out a typo in the new documentation > > - I just noticed that ref-filter understands "%(trailer)", too > (courtesy of Jacob's original series from last year; I didn't think > to even check for it). It probably should learn to support the > additional options, too. I didn't look, but it probably could just > reuse the new trailer.c formatting function I added. > > There's a patch for the second one below. > > None for the other two right now, as I'm just trying to clear out > backlog before going offline for a few days (but I'd be happy if anybody > wanted to take a crack at them in the meantime). Thanks. Have a good time (I am assuming you'd be having fun, as opposed to having to become offline to tend to unpleasant duties). We probably want some convention to mark the messages with these "leftover bits that are relatively low hanging fruits", so that archive search can find them easily. #leftoverbits perhaps? That way, hopefully people can look for messages with such mark that came from those list participants with known-good taste. That would be far easier than a general bug tracker anybody can throw garbage at, and requires constant attention to winnow only good ones out of chaff. > -- >8 -- > From: =?UTF-8?q?Martin=20=C3=85gren?= <martin.agren@xxxxxxxxx> > Subject: [PATCH] doc/interpret-trailers: fix "the this" typo > > Signed-off-by: Jeff King <peff@xxxxxxxx> > --- > I put Martin as the author since he noticed the bug, but I think we are > OK without a signoff for this trivial change (normally I'd have just > squashed, but the topic is in 'next' now). > > Documentation/git-interpret-trailers.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/git-interpret-trailers.txt b/Documentation/git-interpret-trailers.txt > index 1df8aabf51..2e22210734 100644 > --- a/Documentation/git-interpret-trailers.txt > +++ b/Documentation/git-interpret-trailers.txt > @@ -21,7 +21,7 @@ This command reads some patches or commit messages from either the > <file> arguments or the standard input if no <file> is specified. If > `--parse` is specified, the output consists of the parsed trailers. > > -Otherwise, the this command applies the arguments passed using the > +Otherwise, this command applies the arguments passed using the > `--trailer` option, if any, to the commit message part of each input > file. The result is emitted on the standard output.
