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

Merge branch 'dr/ref-filter-push-track-fix'

2019-05-08T15:37:26Z

%(push:track) token used in the --format option to "git for-each-ref" and friends was not showing the right branch, which has been fixed. * dr/ref-filter-push-track-fix: ref-filter: use correct branch for %(push:track)

ref-filter: use correct branch for %(push:track)

2019-04-18T00:17:41Z

In ref-filter.c, when processing the atom %(push:track), the ahead/behind values are computed using `stat_tracking_info` which refers to the upstream branch. Fix that by introducing a new flag `for_push` in `stat_tracking_info` in remote.c, which does the same thing but for the push branch. Update the few callers of `stat_tracking_info` to handle this flag. This ensure that whenever we use this function in the future, we are careful to specify is this should apply to the upstream or the push branch. This bug was not detected in t/t6300-for-each-ref.sh because in the test for push:track, both the upstream and the push branches were behind by 1 from the local branch. Change the test so that the upstream branch is behind by 1 while the push branch is ahead by 1. This allows us to test that %(push:track) refers to the correct branch. This changes the expected value of some following tests (by introducing new references), so update them too. Signed-off-by: Damien Robert Reviewed-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 'nd/completion-more-parameters'

2019-03-07T00:59:58Z

The command line completion (in contrib/) has been taught to complete more subcommand parameters. * nd/completion-more-parameters: completion: add more parameter value completion

completion: add more parameter value completion

2019-02-20T20:31:56Z

This adds value completion for a couple more paramters. To make it easier to maintain these hard coded lists, add a comment at the original list/code to remind people to update git-completion.bash too. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

ref-filter: drop unused "sz" parameters

2019-02-14T23:26:15Z

Many of our grab_* functions, which parse the object content, take a buf/sz pair of the object bytes. However, the functions which actually parse the buffers (like find_wholine() and find_subpos()) never look at "sz", and instead use functions like strchr() and strchrnul() that assume the result is NUL-terminated. This is OK in practice (and common for Git's parsing code), since we always allocate an extra NUL when loading an object into memory (and likewise, we are OK with stopping parsing if a commit or tag contains an embedded NUL). Let's drop these extra "sz" parameters, as they are misleading about how the functions intend to access the buffer. We can drop from both the functions mentioned above, which in turn lets us drop from their callers, cascading all the way up to the top-level grab_values(). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

ref-filter: drop unused "obj" parameters

2019-02-14T23:26:15Z

The grab_person() and grab_sub_body_contents() functions take both an object struct and a buf/sz pair of the object bytes. However, they use only the latter, since "struct object" does not contain the parsed ident (nor the whole commit message, of course). Let's get rid of these misleading "struct object" parameters. It's possible we may want them in the future (e.g., to generate error messages that mention the object id), but since these are static functions, we can easily add them back in later (and if we do want that information, it's likely we'd pass it through a more generalized "parsing context" struct anyway). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

ref-filter: drop unused buf/sz pairs

2019-02-14T23:26:15Z

The grab_tag_values() and grab_commit_values() functions take both the "struct object" as well as the buf/sz pair for the actual object bytes. However, neither function uses the latter, as they pull the data directly from the parsed object struct. Let's get rid of these misleading parameters. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'ot/ref-filter-object-info'

2019-01-18T21:49:56Z

The "--format=" option of for-each-ref, branch and tag learned to show a few more traits of objects that can be learned by the object_info API. * ot/ref-filter-object-info: ref-filter: give uintmax_t to format with %PRIuMAX ref-filter: add docs for new options ref-filter: add tests for deltabase ref-filter: add deltabase option ref-filter: add tests for objectsize:disk ref-filter: add check for negative file size ref-filter: add objectsize:disk option

ref-filter: give uintmax_t to format with %PRIuMAX

2019-01-10T18:15:49Z

As long as we are casting to a wider type, we should cast to the one with the correct signed-ness. Signed-off-by: Junio C Hamano