git/ref-filter.c, branch v2.15.2

Merge branch 'tb/show-trailers-in-ref-filter'

2017-10-11T05:52:22Z

"git for-each-ref --format=..." learned a new format element, %(trailers), to show only the commit log trailer part of the log message. * tb/show-trailers-in-ref-filter: ref-filter.c: parse trailers arguments with %(contents) atom ref-filter.c: use trailer_opts to format trailers t6300: refactor %(trailers) tests doc: use "``"-style quoting for literal strings doc: 'trailers' is the preferred way to format trailers t4205: unfold across multiple lines

Merge branch 'tb/ref-filter-empty-modifier'

2017-10-07T07:27:56Z

In the "--format=..." option of the "git for-each-ref" command (and its friends, i.e. the listing mode of "git branch/tag"), "%(atom:)" (e.g. "%(refname:)", "%(body:)" used to error out. Instead, treat them as if the colon and an empty string that follows it were not there. * tb/ref-filter-empty-modifier: ref-filter.c: pass empty-string as NULL to atom parsers

ref-filter.c: pass empty-string as NULL to atom parsers

2017-10-05T01:41:57Z

Peff points out that different atom parsers handle the empty "sub-argument" list differently. An example of this is the format "%(refname:)". Since callers often use `string_list_split` (which splits the empty string with any delimiter as a 1-ary string_list containing the empty string), this makes handling empty sub-argument strings non-ergonomic. Let's fix this by declaring that atom parser implementations must not care about distinguishing between the empty string "%(refname:)" and no sub-arguments "%(refname)". Current code aborts, either with "unrecognised arg" (e.g. "refname:") or "does not take args" (e.g. "body:") as an error message. Signed-off-by: Taylor Blau Reviewed-by: Jeff King Reviewed-by: Jonathan Nieder Signed-off-by: Junio C Hamano

ref-filter.c: parse trailers arguments with %(contents) atom

2017-10-02T12:15:30Z

The %(contents) atom takes a contents "field" as its argument. Since "trailers" is one of those fields, extend contents_atom_parser to parse "trailers"'s arguments when used through "%(contents)", like: %(contents:trailers:unfold,only) A caveat: trailers_atom_parser expects NULL when no arguments are given (see: `parse_ref_filter_atom`). This is because string_list_split (given a maxsplit of -1) returns a 1-ary string_list* containing the given string if the delimiter could not be found using `strchr`. To simulate this behavior without teaching trailers_atom_parser to accept strings with length zero, conditionally pass NULL to trailers_atom_parser if the arguments portion of the argument to %(contents) is empty. Signed-off-by: Taylor Blau Signed-off-by: Junio C Hamano

ref-filter.c: use trailer_opts to format trailers

2017-10-02T12:15:30Z

Fill trailer_opts with "unfold" and "only" to match the sub-arguments given to the "%(trailers)" atom. Then, let's use the filled trailer_opts instance with 'format_trailers_from_commit' in order to format trailers in the desired manner. Signed-off-by: Taylor Blau Signed-off-by: Junio C Hamano

refs: pass NULL to resolve_refdup() if hash is not needed

2017-10-01T08:27:14Z

This allows us to get rid of several write-only variables. Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

ref-filter: consult want_color() before emitting colors

2017-07-13T19:42:51Z

When color placeholders like %(color:red) are used in a ref-filter format, we unconditionally output the colors, even if the user has asked us for no colors. This usually isn't a problem when the user is constructing a --format on the command line, but it means we may do the wrong thing when the format is fed from a script or alias. For example: $ git config alias.b 'branch --format=%(color:green)%(refname)' $ git b --no-color should probably omit the green color. Likewise, running: $ git b >branches should probably also omit the color, just as we would for all baked-in coloring (and as we recently started to do for user-specified colors in --pretty formats). This commit makes both of those cases work by teaching the ref-filter code to consult want_color() before outputting any color. The color flag in ref_format defaults to "-1", which means we'll consult color.ui, which in turn defaults to the usual isatty() check on stdout. However, callers like git-branch which support their own color config (and command-line options) can override that. The new tests independently cover all three of the callers of ref-filter (for-each-ref, tag, and branch). Even though these seem redundant, it confirms that we've correctly plumbed through all of the necessary config to make colors work by default. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

ref-filter: pass ref_format struct to atom parsers

2017-07-13T19:42:51Z

The callback for parsing each formatting atom gets to see only the atom struct (which it's filling in) and the text to be parsed. This doesn't leave any room for it to behave differently based on context known only to the ref_format. We can solve this by passing in the surrounding ref_format to each parser. Note that this makes things slightly awkward for sort strings, which parse atoms without having a ref_format. We'll solve that by using a dummy ref_format with default parameters. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

ref-filter: factor out the parsing of sorting atoms

2017-07-13T19:42:51Z

We parse sort strings as single formatting atoms, and just build on parse_ref_filter_atom(). Let's pull this idea into its own function, since it's about to get a little more complex. As a bonus, we can give the function a slightly more natural interface, since our single atoms are in their own strings. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

ref-filter: make parse_ref_filter_atom a private function

2017-07-13T19:42:51Z

The parse_ref_filter_atom() function really shouldn't be exposed outside of ref-filter.c; its return value is an integer index into an array that is private in that file. Since the previous commit removed the sole external caller (and replaced it with a public function at a more appropriately level), we can just make this static. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano