git/ref-filter.h, branch v2.22.2

parse_opt_ref_sorting: always use with NONEG flag

2019-03-21T03:03:35Z

The "--sort" parameter of for-each-ref, etc, does not handle negation, and instead returns an error to the parse-options code. But neither piece of code prints anything for the user, which may leave them confused: $ git for-each-ref --no-sort $ echo $? 129 As the comment in the callback function notes, this probably should clear the list, which would make it consistent with other list-like options (i.e., anything that uses OPT_STRING_LIST currently). Unfortunately that's a bit tricky due to the way the ref-filter code works. But in the meantime, let's at least make the error a little less confusing: - switch to using PARSE_OPT_NONEG in the option definition, which will cause the options code to produce a useful message - since this was cut-and-pasted to four different spots, let's define a single OPT_REF_SORT() macro that we can use everywhere - the callback can use BUG_ON_OPT_NEG() to make sure the correct flags are used (incidentally, this also satisfies -Wunused-parameters, since we're now looking at "unset") - expand the comment into a NEEDSWORK to make it clear that the direction is right, but the details need to be worked out Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'ot/libify-get-ref-atom-value'

2018-05-08T06:59:18Z

Code restructuring, in preparation for further work. * ot/libify-get-ref-atom-value: ref-filter: libify get_ref_atom_value() ref-filter: add return value to parsers ref-filter: change parsing function error handling ref-filter: add return value && strbuf to handlers ref-filter: start adding strbufs with errors ref-filter: add shortcut to work with strbufs

ref-filter: factor ref_array pushing into its own function

2018-04-08T21:14:46Z

In preparation for callers constructing their own ref_array structs, let's move our own internal push operation into its own function. While we're at it, we can replace REALLOC_ARRAY() with ALLOC_GROW(), which should give the growth operation amortized linear complexity (as opposed to growing by one, which is potentially quadratic, though in-place realloc growth often makes this faster in practice). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

ref-filter: use "struct object_id" consistently

2018-04-08T21:14:45Z

Internally we store a "struct object_id", and all of our callers have one to pass us. But we insist that they peel it to its bare-sha1 hash, which we then hashcpy() into place. Let's pass it around as an object_id, which future-proofs us for a post-sha1 world. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

ref-filter: start adding strbufs with errors

2018-03-29T21:24:49Z

This is a first step in removing die() calls from ref-filter formatting logic, so that it could be used by other commands that do not want to die during formatting process. die() calls related to bugs in code will not be touched in this patch. Everything would be the same for show_ref_array_item() users. But, if you want to deal with errors by your own, you could invoke format_ref_array_item(). It means that you need to print everything (the result and errors) on your side. This commit changes signature of format_ref_array_item() by adding return value and strbuf parameter for errors, and adjusts its callers. While at it, reduce the scope of the out-variable. Signed-off-by: Olga Telezhnaia 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: 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

ref-filter: provide a function for parsing sort options

2017-07-13T19:42:51Z

The ref-filter module currently provides a callback suitable for parsing command-line --sort options. But since git-tag also supports the tag.sort config option, it needs a function whose implementation is quite similar, but with a slightly different interface. The end result is that builtin/tag.c has a copy-paste of parse_opt_ref_sorting(). Instead, let's provide a function to parse an arbitrary sort string, which we can then trivially wrap to make the parse_opt variant. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

ref-filter: move need_color_reset_at_eol into ref_format

2017-07-13T19:42:50Z

Calling verify_ref_format() doesn't just confirm that the format is sane; it actually sets some global variables that will be used later when formatting the refs. These logically should belong to the ref_format, which would make it possible to use multiple formats within a single program invocation. Let's move one such flag into the ref_format struct. There are still others that would need to be moved before it would be safe to use multiple formats, but this commit gives a blueprint for how that should look. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

ref-filter: abstract ref format into its own struct

2017-07-13T19:42:50Z

The ref-filter module provides routines for formatting a ref for output. The fundamental interface for the format is a "const char *" containing the format, and any additional options need to be passed to each invocation of show_ref_array_item. Instead, let's make a ref_format struct that holds the format, along with any associated format options. That will make some enhancements easier in the future: 1. new formatting options can be added without disrupting existing callers 2. some state can be carried in the struct rather than as global variables For now this just has the text format itself along with the quote_style option, but we'll add more fields in future patches. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano