2007-07-14 23:14:45 +00:00
|
|
|
#include "builtin.h"
|
2017-06-14 18:07:36 +00:00
|
|
|
#include "config.h"
|
2023-03-21 06:25:54 +00:00
|
|
|
#include "gettext.h"
|
2006-09-15 20:30:02 +00:00
|
|
|
#include "refs.h"
|
|
|
|
|
#include "object.h"
|
2007-10-13 18:40:46 +00:00
|
|
|
#include "parse-options.h"
|
2015-06-13 19:37:26 +00:00
|
|
|
#include "ref-filter.h"
|
2023-05-16 06:34:02 +00:00
|
|
|
#include "strbuf.h"
|
2023-03-20 11:26:47 +00:00
|
|
|
#include "strvec.h"
|
for-each-ref: add ahead-behind format atom
The previous change implemented the ahead_behind() method, including an
algorithm to compute the ahead/behind values for a number of commit tips
relative to a number of commit bases. Now, integrate that algorithm as
part of 'git for-each-ref' hidden behind a new format atom,
ahead-behind. This naturally extends to 'git branch' and 'git tag'
builtins, as well.
This format allows specifying multiple bases, if so desired, and all
matching references are compared against all of those bases. For this
reason, failing to read a reference provided from these atoms results in
an error.
In order to translate the ahead_behind() method information to the
format output code in ref-filter.c, we must populate arrays of
ahead_behind_count structs. In struct ref_array, we store the full array
that will be passed to ahead_behind(). In struct ref_array_item, we
store an array of pointers that point to the relvant items within the
full array. In this way, we can pull all relevant ahead/behind values
directly when formatting output for a specific item. It also ensures the
lifetime of the ahead_behind_count structs matches the time that the
array is being used.
Add specific tests of the ahead/behind counts in t6600-test-reach.sh, as
it has an interesting repository shape. In particular, its merging
strategy and its use of different commit-graphs would demonstrate over-
counting if the ahead_behind() method did not already account for that
possibility.
Also add tests for the specific for-each-ref, branch, and tag builtins.
In the case of 'git tag', there are intersting cases that happen when
some of the selected tips are not commits. This requires careful logic
around commits_nr in the second loop of filter_ahead_behind(). Also, the
test in t7004 is carefully located to avoid being dependent on the GPG
prereq. It also avoids using the test_commit helper, as that will add
ticks to the time and disrupt the expected timestamps in later tag
tests.
Also add performance tests in a new p1300-graph-walks.sh script. This
will be useful for more uses in the future, but for now compare the
ahead-behind counting algorithm in 'git for-each-ref' to the naive
implementation by running 'git rev-list --count' processes for each
input.
For the Git source code repository, the improvement is already obvious:
Test this tree
---------------------------------------------------------------
1500.2: ahead-behind counts: git for-each-ref 0.07(0.07+0.00)
1500.3: ahead-behind counts: git branch 0.07(0.06+0.00)
1500.4: ahead-behind counts: git tag 0.07(0.06+0.00)
1500.5: ahead-behind counts: git rev-list 1.32(1.04+0.27)
But the standard performance benchmark is the Linux kernel repository,
which demosntrates a significant improvement:
Test this tree
---------------------------------------------------------------
1500.2: ahead-behind counts: git for-each-ref 0.27(0.24+0.02)
1500.3: ahead-behind counts: git branch 0.27(0.24+0.03)
1500.4: ahead-behind counts: git tag 0.28(0.27+0.01)
1500.5: ahead-behind counts: git rev-list 4.57(4.03+0.54)
The 'git rev-list' test exists in this change as a demonstration, but it
will be removed in the next change to avoid wasting time on this
comparison.
Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-20 11:26:54 +00:00
|
|
|
#include "commit-reach.h"
|
2006-09-15 20:30:02 +00:00
|
|
|
|
2007-10-13 18:40:46 +00:00
|
|
|
static char const * const for_each_ref_usage[] = {
|
2015-01-13 07:44:47 +00:00
|
|
|
N_("git for-each-ref [<options>] [<pattern>]"),
|
2015-07-07 16:06:10 +00:00
|
|
|
N_("git for-each-ref [--points-at <object>]"),
|
2020-09-16 02:08:40 +00:00
|
|
|
N_("git for-each-ref [--merged [<commit>]] [--no-merged [<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-24 18:40:57 +00:00
|
|
|
N_("git for-each-ref [--contains [<commit>]] [--no-contains [<commit>]]"),
|
2007-10-13 18:40:46 +00:00
|
|
|
NULL
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
int cmd_for_each_ref(int argc, const char **argv, const char *prefix)
|
2006-09-15 20:30:02 +00:00
|
|
|
{
|
for-each-ref: delay parsing of --sort=<atom> options
The for-each-ref family of commands invoke parsers immediately when
it sees each --sort=<atom> option, and die before even seeing the
other options on the command line when the <atom> is unrecognised.
Instead, accumulate them in a string list, and have them parsed into
a ref_sorting structure after the command line parsing is done. As
a consequence, "git branch --sort=bogus -h" used to fail to give the
brief help, which arguably may have been a feature, now does so,
which is more consistent with how other options work.
The patch is smaller than the actual extent of the "damage" to the
codebase, thanks to the fact that the original code consistently
used OPT_REF_SORT() macro to handle command line options. We only
needed to replace the variable used for the list, and implementation
of the callback function used in the macro.
The old rule was for the users of the API to:
- Declare ref_sorting and ref_sorting_tail variables;
- OPT_REF_SORT() macro will instantiate ref_sorting instance (which
may barf and die) and append it to the tail;
- Append to the tail each ref_sorting read from the configuration
by parsing in the config callback (which may barf and die);
- See if ref_sorting is null and use ref_sorting_default() instead.
Now the rule is not all that different but is simpler:
- Declare ref_sorting_options string list.
- OPT_REF_SORT() macro will append it to the string list;
- Append to the string list the sort key read from the
configuration;
- call ref_sorting_options() to turn the string list to ref_sorting
structure (which also deals with the default value).
As side effects, this change also cleans up a few issues:
- 95be717c (parse_opt_ref_sorting: always use with NONEG flag,
2019-03-20) muses that "git for-each-ref --no-sort" should simply
clear the sort keys accumulated so far; it now does.
- The implementation detail of "struct ref_sorting" and the helper
function parse_ref_sorting() can now be private to the ref-filter
API implementation.
- If you set branch.sort to a bogus value, the any "git branch"
invocation, not only the listing mode, would abort with the
original code; now it doesn't
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-20 19:23:53 +00:00
|
|
|
struct ref_sorting *sorting;
|
|
|
|
|
struct string_list sorting_options = STRING_LIST_INIT_DUP;
|
2023-11-14 19:53:50 +00:00
|
|
|
int icase = 0;
|
2023-07-10 21:12:07 +00:00
|
|
|
struct ref_filter filter = REF_FILTER_INIT;
|
2017-07-13 15:01:18 +00:00
|
|
|
struct ref_format format = REF_FORMAT_INIT;
|
2023-03-20 11:26:47 +00:00
|
|
|
int from_stdin = 0;
|
|
|
|
|
struct strvec vec = STRVEC_INIT;
|
2006-09-15 20:30:02 +00:00
|
|
|
|
2007-10-13 18:40:46 +00:00
|
|
|
struct option opts[] = {
|
2017-07-13 15:01:18 +00:00
|
|
|
OPT_BIT('s', "shell", &format.quote_style,
|
2012-08-20 12:32:11 +00:00
|
|
|
N_("quote placeholders suitably for shells"), QUOTE_SHELL),
|
2017-07-13 15:01:18 +00:00
|
|
|
OPT_BIT('p', "perl", &format.quote_style,
|
2012-08-20 12:32:11 +00:00
|
|
|
N_("quote placeholders suitably for perl"), QUOTE_PERL),
|
2017-07-13 15:01:18 +00:00
|
|
|
OPT_BIT(0 , "python", &format.quote_style,
|
2012-08-20 12:32:11 +00:00
|
|
|
N_("quote placeholders suitably for python"), QUOTE_PYTHON),
|
2017-07-13 15:01:18 +00:00
|
|
|
OPT_BIT(0 , "tcl", &format.quote_style,
|
2014-11-28 18:00:11 +00:00
|
|
|
N_("quote placeholders suitably for Tcl"), QUOTE_TCL),
|
2023-11-14 19:53:50 +00:00
|
|
|
OPT_BOOL(0, "omit-empty", &format.array_opts.omit_empty,
|
2023-04-07 17:53:16 +00:00
|
|
|
N_("do not output a newline after empty formatted refs")),
|
2007-10-13 18:40:46 +00:00
|
|
|
|
|
|
|
|
OPT_GROUP(""),
|
2023-11-14 19:53:50 +00:00
|
|
|
OPT_INTEGER( 0 , "count", &format.array_opts.max_count, N_("show only <n> matched refs")),
|
2017-07-13 15:01:18 +00:00
|
|
|
OPT_STRING( 0 , "format", &format.format, N_("format"), N_("format to use for the output")),
|
2017-10-03 13:45:47 +00:00
|
|
|
OPT__COLOR(&format.use_color, N_("respect format colors")),
|
builtin/for-each-ref.c: add `--exclude` option
When using `for-each-ref`, it is sometimes convenient for the caller to
be able to exclude certain parts of the references.
For example, if there are many `refs/__hidden__/*` references, the
caller may want to emit all references *except* the hidden ones.
Currently, the only way to do this is to post-process the output, like:
$ git for-each-ref --format='%(refname)' | grep -v '^refs/hidden/'
Which is do-able, but requires processing a potentially large quantity
of references.
Teach `git for-each-ref` a new `--exclude=<pattern>` option, which
excludes references from the results if they match one or more excluded
patterns.
This patch provides a naive implementation where the `ref_filter` still
sees all references (including ones that it will discard) and is left to
check whether each reference matches any excluded pattern(s) before
emitting them.
By culling out references we know the caller doesn't care about, we can
avoid allocating memory for their storage, as well as spending time
sorting the output (among other things). Even the naive implementation
provides a significant speed-up on a modified copy of linux.git (that
has a hidden ref pointing at each commit):
$ hyperfine \
'git.compile for-each-ref --format="%(objectname) %(refname)" | grep -vE "[0-9a-f]{40} refs/pull/"' \
'git.compile for-each-ref --format="%(objectname) %(refname)" --exclude refs/pull/'
Benchmark 1: git.compile for-each-ref --format="%(objectname) %(refname)" | grep -vE "[0-9a-f]{40} refs/pull/"
Time (mean ± σ): 820.1 ms ± 2.0 ms [User: 703.7 ms, System: 152.0 ms]
Range (min … max): 817.7 ms … 823.3 ms 10 runs
Benchmark 2: git.compile for-each-ref --format="%(objectname) %(refname)" --exclude refs/pull/
Time (mean ± σ): 106.6 ms ± 1.1 ms [User: 99.4 ms, System: 7.1 ms]
Range (min … max): 104.7 ms … 109.1 ms 27 runs
Summary
'git.compile for-each-ref --format="%(objectname) %(refname)" --exclude refs/pull/' ran
7.69 ± 0.08 times faster than 'git.compile for-each-ref --format="%(objectname) %(refname)" | grep -vE "[0-9a-f]{40} refs/pull/"'
Subsequent patches will improve on this by avoiding visiting excluded
sections of the `packed-refs` file in certain cases.
Co-authored-by: Jeff King <peff@peff.net>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-07-10 21:12:19 +00:00
|
|
|
OPT_REF_FILTER_EXCLUDE(&filter),
|
for-each-ref: delay parsing of --sort=<atom> options
The for-each-ref family of commands invoke parsers immediately when
it sees each --sort=<atom> option, and die before even seeing the
other options on the command line when the <atom> is unrecognised.
Instead, accumulate them in a string list, and have them parsed into
a ref_sorting structure after the command line parsing is done. As
a consequence, "git branch --sort=bogus -h" used to fail to give the
brief help, which arguably may have been a feature, now does so,
which is more consistent with how other options work.
The patch is smaller than the actual extent of the "damage" to the
codebase, thanks to the fact that the original code consistently
used OPT_REF_SORT() macro to handle command line options. We only
needed to replace the variable used for the list, and implementation
of the callback function used in the macro.
The old rule was for the users of the API to:
- Declare ref_sorting and ref_sorting_tail variables;
- OPT_REF_SORT() macro will instantiate ref_sorting instance (which
may barf and die) and append it to the tail;
- Append to the tail each ref_sorting read from the configuration
by parsing in the config callback (which may barf and die);
- See if ref_sorting is null and use ref_sorting_default() instead.
Now the rule is not all that different but is simpler:
- Declare ref_sorting_options string list.
- OPT_REF_SORT() macro will append it to the string list;
- Append to the string list the sort key read from the
configuration;
- call ref_sorting_options() to turn the string list to ref_sorting
structure (which also deals with the default value).
As side effects, this change also cleans up a few issues:
- 95be717c (parse_opt_ref_sorting: always use with NONEG flag,
2019-03-20) muses that "git for-each-ref --no-sort" should simply
clear the sort keys accumulated so far; it now does.
- The implementation detail of "struct ref_sorting" and the helper
function parse_ref_sorting() can now be private to the ref-filter
API implementation.
- If you set branch.sort to a bogus value, the any "git branch"
invocation, not only the listing mode, would abort with the
original code; now it doesn't
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-20 19:23:53 +00:00
|
|
|
OPT_REF_SORT(&sorting_options),
|
2015-07-07 16:06:10 +00:00
|
|
|
OPT_CALLBACK(0, "points-at", &filter.points_at,
|
|
|
|
|
N_("object"), N_("print only refs which points at the given object"),
|
|
|
|
|
parse_opt_object_name),
|
2015-07-07 16:06:13 +00:00
|
|
|
OPT_MERGED(&filter, N_("print only refs that are merged")),
|
|
|
|
|
OPT_NO_MERGED(&filter, N_("print only refs that are not merged")),
|
2015-07-07 16:06:17 +00:00
|
|
|
OPT_CONTAINS(&filter.with_commit, N_("print only refs which contain the 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-24 18:40:57 +00:00
|
|
|
OPT_NO_CONTAINS(&filter.no_commit, N_("print only refs which don't contain the commit")),
|
2016-12-04 02:52:25 +00:00
|
|
|
OPT_BOOL(0, "ignore-case", &icase, N_("sorting and filtering are case insensitive")),
|
2023-03-20 11:26:47 +00:00
|
|
|
OPT_BOOL(0, "stdin", &from_stdin, N_("read reference patterns from stdin")),
|
2007-10-13 18:40:46 +00:00
|
|
|
OPT_END(),
|
|
|
|
|
};
|
|
|
|
|
|
2017-07-13 15:01:18 +00:00
|
|
|
format.format = "%(objectname) %(objecttype)\t%(refname)";
|
|
|
|
|
|
2017-07-13 15:07:14 +00:00
|
|
|
git_config(git_default_config, NULL);
|
|
|
|
|
|
ref-filter.c: really don't sort when using --no-sort
When '--no-sort' is passed to 'for-each-ref', 'tag', and 'branch', the
printed refs are still sorted by ascending refname. Change the handling of
sort options in these commands so that '--no-sort' to truly disables
sorting.
'--no-sort' does not disable sorting in these commands is because their
option parsing does not distinguish between "the absence of '--sort'"
(and/or values for tag.sort & branch.sort) and '--no-sort'. Both result in
an empty 'sorting_options' string list, which is parsed by
'ref_sorting_options()' to create the 'struct ref_sorting *' for the
command. If the string list is empty, 'ref_sorting_options()' interprets
that as "the absence of '--sort'" and returns the default ref sorting
structure (equivalent to "refname" sort).
To handle '--no-sort' properly while preserving the "refname" sort in the
"absence of --sort'" case, first explicitly add "refname" to the string list
*before* parsing options. This alone doesn't actually change any behavior,
since 'compare_refs()' already falls back on comparing refnames if two refs
are equal w.r.t all other sort keys.
Now that the string list is populated by default, '--no-sort' is the only
way to empty the 'sorting_options' string list. Update
'ref_sorting_options()' to return a NULL 'struct ref_sorting *' if the
string list is empty, and add a condition to 'ref_array_sort()' to skip the
sort altogether if the sort structure is NULL. Note that other functions
using 'struct ref_sorting *' do not need any changes because they already
ignore NULL values.
Finally, remove the condition around sorting in 'ls-remote', since it's no
longer necessary. Unlike 'for-each-ref' et. al., it does *not* do any
sorting by default. This default is preserved by simply leaving its sort key
string list empty before parsing options; if no additional sort keys are
set, 'struct ref_sorting *' is NULL and sorting is skipped.
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-11-14 19:53:49 +00:00
|
|
|
/* Set default (refname) sorting */
|
|
|
|
|
string_list_append(&sorting_options, "refname");
|
|
|
|
|
|
2009-05-23 18:53:12 +00:00
|
|
|
parse_options(argc, argv, prefix, opts, for_each_ref_usage, 0);
|
2023-11-14 19:53:50 +00:00
|
|
|
if (format.array_opts.max_count < 0) {
|
|
|
|
|
error("invalid --count argument: `%d'", format.array_opts.max_count);
|
2007-10-13 18:40:46 +00:00
|
|
|
usage_with_options(for_each_ref_usage, opts);
|
2006-09-15 20:30:02 +00:00
|
|
|
}
|
2017-07-13 15:01:18 +00:00
|
|
|
if (HAS_MULTI_BITS(format.quote_style)) {
|
2007-12-06 12:24:39 +00:00
|
|
|
error("more than one quoting style?");
|
2007-10-13 18:40:46 +00:00
|
|
|
usage_with_options(for_each_ref_usage, opts);
|
|
|
|
|
}
|
2017-07-13 15:01:18 +00:00
|
|
|
if (verify_ref_format(&format))
|
2007-10-13 18:40:46 +00:00
|
|
|
usage_with_options(for_each_ref_usage, opts);
|
2006-09-15 20:30:02 +00:00
|
|
|
|
for-each-ref: delay parsing of --sort=<atom> options
The for-each-ref family of commands invoke parsers immediately when
it sees each --sort=<atom> option, and die before even seeing the
other options on the command line when the <atom> is unrecognised.
Instead, accumulate them in a string list, and have them parsed into
a ref_sorting structure after the command line parsing is done. As
a consequence, "git branch --sort=bogus -h" used to fail to give the
brief help, which arguably may have been a feature, now does so,
which is more consistent with how other options work.
The patch is smaller than the actual extent of the "damage" to the
codebase, thanks to the fact that the original code consistently
used OPT_REF_SORT() macro to handle command line options. We only
needed to replace the variable used for the list, and implementation
of the callback function used in the macro.
The old rule was for the users of the API to:
- Declare ref_sorting and ref_sorting_tail variables;
- OPT_REF_SORT() macro will instantiate ref_sorting instance (which
may barf and die) and append it to the tail;
- Append to the tail each ref_sorting read from the configuration
by parsing in the config callback (which may barf and die);
- See if ref_sorting is null and use ref_sorting_default() instead.
Now the rule is not all that different but is simpler:
- Declare ref_sorting_options string list.
- OPT_REF_SORT() macro will append it to the string list;
- Append to the string list the sort key read from the
configuration;
- call ref_sorting_options() to turn the string list to ref_sorting
structure (which also deals with the default value).
As side effects, this change also cleans up a few issues:
- 95be717c (parse_opt_ref_sorting: always use with NONEG flag,
2019-03-20) muses that "git for-each-ref --no-sort" should simply
clear the sort keys accumulated so far; it now does.
- The implementation detail of "struct ref_sorting" and the helper
function parse_ref_sorting() can now be private to the ref-filter
API implementation.
- If you set branch.sort to a bogus value, the any "git branch"
invocation, not only the listing mode, would abort with the
original code; now it doesn't
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-20 19:23:53 +00:00
|
|
|
sorting = ref_sorting_options(&sorting_options);
|
2021-01-07 09:51:51 +00:00
|
|
|
ref_sorting_set_sort_flags_all(sorting, REF_SORTING_ICASE, icase);
|
2016-12-04 02:52:25 +00:00
|
|
|
filter.ignore_case = icase;
|
2006-09-15 20:30:02 +00:00
|
|
|
|
2023-03-20 11:26:47 +00:00
|
|
|
if (from_stdin) {
|
|
|
|
|
struct strbuf line = STRBUF_INIT;
|
|
|
|
|
|
|
|
|
|
if (argv[0])
|
|
|
|
|
die(_("unknown arguments supplied with --stdin"));
|
|
|
|
|
|
|
|
|
|
while (strbuf_getline(&line, stdin) != EOF)
|
|
|
|
|
strvec_push(&vec, line.buf);
|
|
|
|
|
|
|
|
|
|
strbuf_release(&line);
|
|
|
|
|
|
|
|
|
|
/* vec.v is NULL-terminated, just like 'argv'. */
|
|
|
|
|
filter.name_patterns = vec.v;
|
|
|
|
|
} else {
|
|
|
|
|
filter.name_patterns = argv;
|
|
|
|
|
}
|
|
|
|
|
|
2015-09-10 15:48:26 +00:00
|
|
|
filter.match_as_path = 1;
|
2023-11-14 19:53:52 +00:00
|
|
|
filter_and_format_refs(&filter, FILTER_REFS_ALL, sorting, &format);
|
2021-04-20 16:52:11 +00:00
|
|
|
|
2023-07-10 21:12:13 +00:00
|
|
|
ref_filter_clear(&filter);
|
2021-10-20 18:27:20 +00:00
|
|
|
ref_sorting_release(sorting);
|
2023-03-20 11:26:47 +00:00
|
|
|
strvec_clear(&vec);
|
2006-09-15 20:30:02 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|