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

ref-filter: make internal reachable-filter API more precise

2020-09-18T22:41:55Z

The internal reachable-filter API is a bit loose and imprecise; it also bleeds unnecessarily into the public header. Tighten the API by: * renaming do_merge_filter() to reach_filter() * separating parameters to explicitly identify what data is used by the function instead of passing an entire ref_filter_cbdata struct * renaming and moving internal constants from header to source file Signed-off-by: Aaron Lipman Signed-off-by: Junio C Hamano

ref-filter: allow merged and no-merged filters

2020-09-16T19:38:10Z

Enable ref-filter to process multiple merged and no-merged filters, and extend functionality to git branch, git tag and git for-each-ref. This provides an easy way to check for branches that are "graduation candidates:" $ git branch --no-merged master --merged next If passed more than one merged (or more than one no-merged) filter, refs must be reachable from any one of the merged commits, and reachable from none of the no-merged commits. Signed-off-by: Aaron Lipman Signed-off-by: Junio C Hamano

Merge branch 'jk/for-each-ref-multi-key-sort-fix'

2020-05-08T21:25:04Z

"git branch" and other "for-each-ref" variants accepted multiple --sort= options in the increasing order of precedence, but it had a few breakages around "--ignore-case" handling, and tie-breaking with the refname, which have been fixed. * jk/for-each-ref-multi-key-sort-fix: ref-filter: apply fallback refname sort only after all user sorts ref-filter: apply --ignore-case to all sorting keys

ref-filter: apply --ignore-case to all sorting keys

2020-05-04T20:41:20Z

All of the ref-filter users (for-each-ref, branch, and tag) take an --ignore-case option which makes filtering and sorting case-insensitive. However, this option was applied only to the first element of the ref_sorting list. So: git for-each-ref --ignore-case --sort=refname would do what you expect, but: git for-each-ref --ignore-case --sort=refname --sort=taggername would sort the primary key (taggername) case-insensitively, but sort the refname case-sensitively. We have two options here: - teach callers to set ignore_case on the whole list - replace the ref_sorting list with a struct that contains both the list of sorting keys, as well as options that apply to _all_ keys I went with the first one here, as it gives more flexibility if we later want to let the users set the flag per-key (presumably through some special syntax when defining the key; for now it's all or nothing through --ignore-case). The new test covers this by sorting on both tagger and subject case-insensitively, which should compare "a" and "A" identically, but still sort them before "b" and "B". We'll break ties by sorting on the refname to give ourselves a stable output (this is actually supposed to be done automatically, but there's another bug which will be fixed in the next commit). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

oid_array: rename source file from sha1-array

2020-03-30T17:59:08Z

We renamed the actual data structure in 910650d2f8 (Rename sha1_array to oid_array, 2017-03-31), but the file is still called sha1-array. Besides being slightly confusing, it makes it more annoying to grep for leftover occurrences of "sha1" in various files, because the header is included in so many places. Let's complete the transition by renaming the source and header files (and fixing up a few comment references). I kept the "-" in the name, as that seems to be our style; cf. fc1395f4a4 (sha1_file.c: rename to use dash in file name, 2018-04-10). We also have oidmap.h and oidset.h without any punctuation, but those are "struct oidmap" and "struct oidset" in the code. We _could_ make this "oidarray" to match, but somehow it looks uglier to me because of the length of "array" (plus it would be a very invasive patch for little gain). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

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