2015-06-14 03:37:26 +08:00
|
|
|
#ifndef REF_FILTER_H
|
|
|
|
#define REF_FILTER_H
|
|
|
|
|
2020-03-30 22:03:46 +08:00
|
|
|
#include "oid-array.h"
|
2015-06-14 03:37:26 +08:00
|
|
|
#include "refs.h"
|
|
|
|
#include "commit.h"
|
|
|
|
#include "parse-options.h"
|
|
|
|
|
|
|
|
/* Quoting styles */
|
|
|
|
#define QUOTE_NONE 0
|
|
|
|
#define QUOTE_SHELL 1
|
|
|
|
#define QUOTE_PERL 2
|
|
|
|
#define QUOTE_PYTHON 4
|
|
|
|
#define QUOTE_TCL 8
|
|
|
|
|
2015-09-10 23:48:23 +08:00
|
|
|
#define FILTER_REFS_INCLUDE_BROKEN 0x0001
|
|
|
|
#define FILTER_REFS_TAGS 0x0002
|
|
|
|
#define FILTER_REFS_BRANCHES 0x0004
|
|
|
|
#define FILTER_REFS_REMOTES 0x0008
|
|
|
|
#define FILTER_REFS_OTHERS 0x0010
|
|
|
|
#define FILTER_REFS_ALL (FILTER_REFS_TAGS | FILTER_REFS_BRANCHES | \
|
|
|
|
FILTER_REFS_REMOTES | FILTER_REFS_OTHERS)
|
|
|
|
#define FILTER_REFS_DETACHED_HEAD 0x0020
|
|
|
|
#define FILTER_REFS_KIND_MASK (FILTER_REFS_ALL | FILTER_REFS_DETACHED_HEAD)
|
2015-06-14 03:37:28 +08:00
|
|
|
|
2015-08-22 11:39:37 +08:00
|
|
|
struct atom_value;
|
2015-06-14 03:37:26 +08:00
|
|
|
|
|
|
|
struct ref_sorting {
|
|
|
|
struct ref_sorting *next;
|
|
|
|
int atom; /* index into used_atom array (internal) */
|
2021-01-07 17:51:51 +08:00
|
|
|
enum {
|
|
|
|
REF_SORTING_REVERSE = 1<<0,
|
|
|
|
REF_SORTING_ICASE = 1<<1,
|
|
|
|
REF_SORTING_VERSION = 1<<2,
|
branch: sort detached HEAD based on a flag
Change the ref-filter sorting of detached HEAD to check the
FILTER_REFS_DETACHED_HEAD flag, instead of relying on the ref
description filled-in by get_head_description() to start with "(",
which in turn we expect to ASCII-sort before any other reference.
For context, we'd like the detached line to appear first at the start
of "git branch -l", e.g.:
$ git branch -l
* (HEAD detached at <hash>)
master
This doesn't change that, but improves on a fix made in
28438e84e04 (ref-filter: sort detached HEAD lines firstly, 2019-06-18)
and gives the Chinese translation the ability to use its preferred
punctuation marks again.
In Chinese the fullwidth versions of punctuation like "()" are
typically written as (U+FF08 fullwidth left parenthesis), (U+FF09
fullwidth right parenthesis) instead[1]. This form is used in both
po/zh_{CN,TW}.po in most cases where "()" is translated in a string.
Aside from that improvement to the Chinese translation, it also just
makes for cleaner code that we mark any special cases in the ref_array
we're sorting with flags and make the sort function aware of them,
instead of piggy-backing on the general-case of strcmp() doing the
right thing.
As seen in the amended tests this made reverse sorting a bit more
consistent. Before this we'd sometimes sort this message in the
middle, now it's consistently at the beginning or end, depending on
whether we're doing a normal or reverse sort. Having it at the end
doesn't make much sense either, but at least it behaves consistently
now. A follow-up commit will make this behavior under reverse sorting
even better.
I'm removing the "TRANSLATORS" comments that were in the old code
while I'm at it. Those were added in d4919bb288e (ref-filter: move
get_head_description() from branch.c, 2017-01-10). I think it's
obvious from context, string and translation memory in typical
translation tools that these are the same or similar string.
1. https://en.wikipedia.org/wiki/Chinese_punctuation#Marks_similar_to_European_punctuation
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-07 17:51:52 +08:00
|
|
|
REF_SORTING_DETACHED_HEAD_FIRST = 1<<3,
|
2021-01-07 17:51:51 +08:00
|
|
|
} sort_flags;
|
2015-06-14 03:37:26 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
struct ref_array_item {
|
2017-05-07 06:10:21 +08:00
|
|
|
struct object_id objectname;
|
2015-06-14 03:37:26 +08:00
|
|
|
int flag;
|
2015-09-10 23:48:23 +08:00
|
|
|
unsigned int kind;
|
2015-06-14 03:37:26 +08:00
|
|
|
const char *symref;
|
2015-07-08 00:06:12 +08:00
|
|
|
struct commit *commit;
|
2015-06-14 03:37:26 +08:00
|
|
|
struct atom_value *value;
|
2015-06-14 03:37:29 +08:00
|
|
|
char refname[FLEX_ARRAY];
|
2015-06-14 03:37:26 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
struct ref_array {
|
|
|
|
int nr, alloc;
|
|
|
|
struct ref_array_item **items;
|
2015-09-24 02:11:11 +08:00
|
|
|
struct rev_info *revs;
|
2015-06-14 03:37:26 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
struct ref_filter {
|
|
|
|
const char **name_patterns;
|
2017-03-31 09:40:00 +08:00
|
|
|
struct oid_array points_at;
|
2015-07-08 00:06:16 +08:00
|
|
|
struct commit_list *with_commit;
|
ref-filter: add --no-contains option to tag/branch/for-each-ref
Change the tag, branch & for-each-ref commands to have a --no-contains
option in addition to their longstanding --contains options.
This allows for finding the last-good rollout tag given a known-bad
<commit>. Given a hypothetically bad commit cf5c7253e0, the git
version to revert to can be found with this hacky two-liner:
(git tag -l 'v[0-9]*'; git tag -l --contains cf5c7253e0 'v[0-9]*') |
sort | uniq -c | grep -E '^ *1 ' | awk '{print $2}' | tail -n 10
With this new --no-contains option the same can be achieved with:
git tag -l --no-contains cf5c7253e0 'v[0-9]*' | sort | tail -n 10
As the filtering machinery is shared between the tag, branch &
for-each-ref commands, implement this for those commands too. A
practical use for this with "branch" is e.g. finding branches which
were branched off between v2.8.0 and v2.10.0:
git branch --contains v2.8.0 --no-contains v2.10.0
The "describe" command also has a --contains option, but its semantics
are unrelated to what tag/branch/for-each-ref use --contains for. A
--no-contains option for "describe" wouldn't make any sense, other
than being exactly equivalent to not supplying --contains at all,
which would be confusing at best.
Add a --without option to "tag" as an alias for --no-contains, for
consistency with --with and --contains. The --with option is
undocumented, and possibly the only user of it is
Junio (<xmqqefy71iej.fsf@gitster.mtv.corp.google.com>). But it's
trivial to support, so let's do that.
The additions to the the test suite are inverse copies of the
corresponding --contains tests. With this change --no-contains for
tag, branch & for-each-ref is just as well tested as the existing
--contains option.
In addition to those tests, add a test for "tag" which asserts that
--no-contains won't find tree/blob tags, which is slightly
unintuitive, but consistent with how --contains works & is documented.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-25 02:40:57 +08:00
|
|
|
struct commit_list *no_commit;
|
2020-09-16 10:08:40 +08:00
|
|
|
struct commit_list *reachable_from;
|
|
|
|
struct commit_list *unreachable_from;
|
2015-07-08 00:06:16 +08:00
|
|
|
|
2015-09-10 23:48:26 +08:00
|
|
|
unsigned int with_commit_tag_algo : 1,
|
2015-09-24 02:11:11 +08:00
|
|
|
match_as_path : 1,
|
2016-12-04 10:52:25 +08:00
|
|
|
ignore_case : 1,
|
2015-09-24 02:11:11 +08:00
|
|
|
detached : 1;
|
2015-09-11 23:04:16 +08:00
|
|
|
unsigned int kind,
|
|
|
|
lines;
|
2015-09-24 02:11:11 +08:00
|
|
|
int abbrev,
|
|
|
|
verbose;
|
2015-06-14 03:37:26 +08:00
|
|
|
};
|
|
|
|
|
2017-07-13 23:01:18 +08:00
|
|
|
struct ref_format {
|
|
|
|
/*
|
|
|
|
* Set these to define the format; make sure you call
|
|
|
|
* verify_ref_format() afterwards to finalize.
|
|
|
|
*/
|
|
|
|
const char *format;
|
|
|
|
int quote_style;
|
ref-filter: consult want_color() before emitting colors
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 <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13 23:09:32 +08:00
|
|
|
int use_color;
|
2017-07-13 23:02:30 +08:00
|
|
|
|
|
|
|
/* Internal state to ref-filter */
|
|
|
|
int need_color_reset_at_eol;
|
2017-07-13 23:01:18 +08:00
|
|
|
};
|
|
|
|
|
ref-filter: consult want_color() before emitting colors
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 <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13 23:09:32 +08:00
|
|
|
#define REF_FORMAT_INIT { NULL, 0, -1 }
|
2017-07-13 23:01:18 +08:00
|
|
|
|
2015-07-08 00:06:11 +08:00
|
|
|
/* Macros for checking --merged and --no-merged options */
|
|
|
|
#define _OPT_MERGED_NO_MERGED(option, filter, h) \
|
|
|
|
{ OPTION_CALLBACK, 0, option, (filter), N_("commit"), (h), \
|
|
|
|
PARSE_OPT_LASTARG_DEFAULT | PARSE_OPT_NONEG, \
|
|
|
|
parse_opt_merge_filter, (intptr_t) "HEAD" \
|
|
|
|
}
|
|
|
|
#define OPT_MERGED(f, h) _OPT_MERGED_NO_MERGED("merged", f, h)
|
|
|
|
#define OPT_NO_MERGED(f, h) _OPT_MERGED_NO_MERGED("no-merged", f, h)
|
|
|
|
|
parse_opt_ref_sorting: always use with NONEG flag
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 <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-21 04:22:15 +08:00
|
|
|
#define OPT_REF_SORT(var) \
|
|
|
|
OPT_CALLBACK_F(0, "sort", (var), \
|
|
|
|
N_("key"), N_("field name to sort on"), \
|
|
|
|
PARSE_OPT_NONEG, parse_opt_ref_sorting)
|
|
|
|
|
2015-06-14 03:37:28 +08:00
|
|
|
/*
|
|
|
|
* API for filtering a set of refs. Based on the type of refs the user
|
|
|
|
* has requested, we iterate through those refs and apply filters
|
|
|
|
* as per the given ref_filter structure and finally store the
|
|
|
|
* filtered refs in the ref_array structure.
|
|
|
|
*/
|
|
|
|
int filter_refs(struct ref_array *array, struct ref_filter *filter, unsigned int type);
|
2015-06-14 03:37:26 +08:00
|
|
|
/* Clear all memory allocated to ref_array */
|
|
|
|
void ref_array_clear(struct ref_array *array);
|
|
|
|
/* Used to verify if the given format is correct and to parse out the used atoms */
|
2017-07-13 23:01:18 +08:00
|
|
|
int verify_ref_format(struct ref_format *format);
|
2015-06-14 03:37:26 +08:00
|
|
|
/* Sort the given ref_array as per the ref_sorting provided */
|
|
|
|
void ref_array_sort(struct ref_sorting *sort, struct ref_array *array);
|
2021-01-07 17:51:51 +08:00
|
|
|
/* Set REF_SORTING_* sort_flags for all elements of a sorting list */
|
|
|
|
void ref_sorting_set_sort_flags_all(struct ref_sorting *sorting, unsigned int mask, int on);
|
2017-01-10 16:49:39 +08:00
|
|
|
/* Based on the given format and quote_style, fill the strbuf */
|
2018-03-29 20:49:45 +08:00
|
|
|
int format_ref_array_item(struct ref_array_item *info,
|
|
|
|
const struct ref_format *format,
|
|
|
|
struct strbuf *final_buf,
|
|
|
|
struct strbuf *error_buf);
|
2017-07-13 23:02:44 +08:00
|
|
|
/* Parse a single sort specifier and add it to the list */
|
|
|
|
void parse_ref_sorting(struct ref_sorting **sorting_tail, const char *atom);
|
2015-06-14 03:37:26 +08:00
|
|
|
/* Callback function for parsing the sort option */
|
|
|
|
int parse_opt_ref_sorting(const struct option *opt, const char *arg, int unset);
|
|
|
|
/* Default sort option based on refname */
|
|
|
|
struct ref_sorting *ref_default_sorting(void);
|
2015-07-08 00:06:11 +08:00
|
|
|
/* Function to parse --merged and --no-merged options */
|
|
|
|
int parse_opt_merge_filter(const struct option *opt, const char *arg, int unset);
|
2017-01-10 16:49:38 +08:00
|
|
|
/* Get the current HEAD's description */
|
|
|
|
char *get_head_description(void);
|
2017-01-10 16:49:50 +08:00
|
|
|
/* Set up translated strings in the output. */
|
|
|
|
void setup_ref_filter_porcelain_msg(void);
|
2015-06-14 03:37:26 +08:00
|
|
|
|
2017-01-18 07:37:19 +08:00
|
|
|
/*
|
|
|
|
* Print a single ref, outside of any ref-filter. Note that the
|
|
|
|
* name must be a fully qualified refname.
|
|
|
|
*/
|
2018-04-07 02:58:32 +08:00
|
|
|
void pretty_print_ref(const char *name, const struct object_id *oid,
|
2017-07-13 23:01:18 +08:00
|
|
|
const struct ref_format *format);
|
2017-01-18 07:37:19 +08:00
|
|
|
|
2018-04-07 02:59:45 +08:00
|
|
|
/*
|
|
|
|
* Push a single ref onto the array; this can be used to construct your own
|
|
|
|
* ref_array without using filter_refs().
|
|
|
|
*/
|
|
|
|
struct ref_array_item *ref_array_push(struct ref_array *array,
|
|
|
|
const char *refname,
|
|
|
|
const struct object_id *oid);
|
|
|
|
|
2015-06-14 03:37:26 +08:00
|
|
|
#endif /* REF_FILTER_H */
|