2007-10-30 01:05:43 +00:00
|
|
|
#include "builtin.h"
|
2023-03-21 06:25:54 +00:00
|
|
|
#include "gettext.h"
|
2023-02-24 00:09:27 +00:00
|
|
|
#include "hex.h"
|
2007-10-30 01:05:43 +00:00
|
|
|
#include "transport.h"
|
2023-04-22 20:17:14 +00:00
|
|
|
#include "pkt-line.h"
|
2018-04-09 01:42:26 +00:00
|
|
|
#include "ref-filter.h"
|
2007-10-30 01:05:43 +00:00
|
|
|
#include "remote.h"
|
treewide: include parse-options.h in source files
The builtins 'ls-remote', 'pack-objects', 'receive-pack', 'reflog' and
'send-pack' use parse_options(), but their source files don't directly
include 'parse-options.h'. Furthermore, the source files
'diagnose.c', 'list-objects-filter-options.c', 'remote.c' and
'send-pack.c' define option parsing callback functions, while
'revision.c' defines an option parsing helper function, and thus need
access to various fields in 'struct option' and 'struct
parse_opt_ctx_t', but they don't directly include 'parse-options.h'
either. They all can still be built, of course, because they include
one of the header files that does include 'parse-options.h' (though
unnecessarily, see the next commit).
Add those missing includes to these files, as our general rule is that
"a C file must directly include the header files that declare the
functions and the types it uses".
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Reviewed-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-19 16:27:11 +00:00
|
|
|
#include "parse-options.h"
|
2023-05-16 06:34:03 +00:00
|
|
|
#include "wildmatch.h"
|
2005-07-24 00:54:03 +00:00
|
|
|
|
2016-01-18 23:20:49 +00:00
|
|
|
static const char * const ls_remote_usage[] = {
|
|
|
|
|
N_("git ls-remote [--heads] [--tags] [--refs] [--upload-pack=<exec>]\n"
|
2022-10-13 15:39:13 +00:00
|
|
|
" [-q | --quiet] [--exit-code] [--get-url] [--sort=<key>]\n"
|
2023-02-11 04:52:56 +00:00
|
|
|
" [--symref] [<repository> [<patterns>...]]"),
|
2016-01-18 23:20:49 +00:00
|
|
|
NULL
|
|
|
|
|
};
|
2005-07-24 00:54:03 +00:00
|
|
|
|
2007-12-09 06:52:59 +00:00
|
|
|
/*
|
2007-12-09 20:16:55 +00:00
|
|
|
* Is there one among the list of patterns that match the tail part
|
|
|
|
|
* of the path?
|
2007-12-09 06:52:59 +00:00
|
|
|
*/
|
|
|
|
|
static int tail_match(const char **pattern, const char *path)
|
|
|
|
|
{
|
|
|
|
|
const char *p;
|
2017-03-28 19:46:30 +00:00
|
|
|
char *pathbuf;
|
2007-12-09 06:52:59 +00:00
|
|
|
|
2007-12-09 20:16:55 +00:00
|
|
|
if (!pattern)
|
2007-12-09 06:52:59 +00:00
|
|
|
return 1; /* no restriction */
|
|
|
|
|
|
2017-03-28 19:46:30 +00:00
|
|
|
pathbuf = xstrfmt("/%s", path);
|
2007-12-09 20:16:55 +00:00
|
|
|
while ((p = *(pattern++)) != NULL) {
|
2017-06-22 21:38:08 +00:00
|
|
|
if (!wildmatch(p, pathbuf, 0)) {
|
2017-03-28 19:46:30 +00:00
|
|
|
free(pathbuf);
|
2007-12-09 20:16:55 +00:00
|
|
|
return 1;
|
2017-03-28 19:46:30 +00:00
|
|
|
}
|
2007-12-09 06:52:59 +00:00
|
|
|
}
|
2017-03-28 19:46:30 +00:00
|
|
|
free(pathbuf);
|
2007-12-09 06:52:59 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2007-11-04 20:51:17 +00:00
|
|
|
int cmd_ls_remote(int argc, const char **argv, const char *prefix)
|
2005-07-24 00:54:03 +00:00
|
|
|
{
|
2007-10-30 01:05:43 +00:00
|
|
|
const char *dest = NULL;
|
Improve git-peek-remote
This makes git-peek-remote able to basically do everything that
git-ls-remote does (but obviously just for the native protocol, so no
http[s]: or rsync: support).
The default behaviour is the same, but you can now give a mixture of
"--refs", "--tags" and "--heads" flags, where "--refs" forces
git-peek-remote to only show real refs (ie none of the fakey tag lookups,
but also not the special pseudo-refs like HEAD and MERGE_HEAD).
The "--tags" and "--heads" flags respectively limit the output to just
regular tags and heads, of course.
You can still also ask to limit them by name too.
You can combine the flags, so
git peek-remote --refs --tags .
will show all local _true_ tags, without the generated tag lookups
(compare the output without the "--refs" flag).
And "--tags --heads" will show both tags and heads, but will avoid (for
example) any special refs outside of the standard locations.
I'm also planning on adding a "--ignore-local" flag that allows us to ask
it to ignore any refs that we already have in the local tree, but that's
an independent thing.
All this is obviously gearing up to making "git fetch" cheaper.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-04 19:29:10 +00:00
|
|
|
unsigned flags = 0;
|
2011-03-01 09:21:36 +00:00
|
|
|
int get_url = 0;
|
2010-05-11 17:20:23 +00:00
|
|
|
int quiet = 0;
|
2011-05-18 20:06:00 +00:00
|
|
|
int status = 0;
|
2016-01-18 23:20:50 +00:00
|
|
|
int show_symref_target = 0;
|
2007-10-30 01:05:43 +00:00
|
|
|
const char *uploadpack = NULL;
|
2007-12-09 06:52:59 +00:00
|
|
|
const char **pattern = NULL;
|
2021-02-05 20:48:48 +00:00
|
|
|
struct transport_ls_refs_options transport_options =
|
|
|
|
|
TRANSPORT_LS_REFS_OPTIONS_INIT;
|
2018-04-09 01:42:26 +00:00
|
|
|
int i;
|
2018-04-23 22:46:23 +00:00
|
|
|
struct string_list server_options = STRING_LIST_INIT_DUP;
|
2007-10-30 01:05:43 +00:00
|
|
|
|
2007-11-07 01:29:20 +00:00
|
|
|
struct remote *remote;
|
2007-10-30 01:05:43 +00:00
|
|
|
struct transport *transport;
|
|
|
|
|
const struct ref *ref;
|
2018-04-09 01:42:26 +00:00
|
|
|
struct ref_array ref_array;
|
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
|
|
|
struct ref_sorting *sorting;
|
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 string_list sorting_options = STRING_LIST_INIT_DUP;
|
2005-11-26 07:50:21 +00:00
|
|
|
|
2016-01-18 23:20:49 +00:00
|
|
|
struct option options[] = {
|
|
|
|
|
OPT__QUIET(&quiet, N_("do not print remote URL")),
|
|
|
|
|
OPT_STRING(0, "upload-pack", &uploadpack, N_("exec"),
|
|
|
|
|
N_("path of git-upload-pack on the remote host")),
|
|
|
|
|
{ OPTION_STRING, 0, "exec", &uploadpack, N_("exec"),
|
|
|
|
|
N_("path of git-upload-pack on the remote host"),
|
|
|
|
|
PARSE_OPT_HIDDEN },
|
|
|
|
|
OPT_BIT('t', "tags", &flags, N_("limit to tags"), REF_TAGS),
|
|
|
|
|
OPT_BIT('h', "heads", &flags, N_("limit to heads"), REF_HEADS),
|
|
|
|
|
OPT_BIT(0, "refs", &flags, N_("do not show peeled tags"), REF_NORMAL),
|
|
|
|
|
OPT_BOOL(0, "get-url", &get_url,
|
|
|
|
|
N_("take url.<base>.insteadOf into account")),
|
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),
|
2018-02-09 11:02:03 +00:00
|
|
|
OPT_SET_INT_F(0, "exit-code", &status,
|
|
|
|
|
N_("exit with exit code 2 if no matching refs are found"),
|
|
|
|
|
2, PARSE_OPT_NOCOMPLETE),
|
2016-01-18 23:20:50 +00:00
|
|
|
OPT_BOOL(0, "symref", &show_symref_target,
|
|
|
|
|
N_("show underlying ref in addition to the object pointed by it")),
|
2018-04-23 22:46:23 +00:00
|
|
|
OPT_STRING_LIST('o', "server-option", &server_options, N_("server-specific"), N_("option to transmit")),
|
2016-01-18 23:20:49 +00:00
|
|
|
OPT_END()
|
|
|
|
|
};
|
2011-09-16 18:14:27 +00:00
|
|
|
|
2018-04-09 01:42:26 +00:00
|
|
|
memset(&ref_array, 0, sizeof(ref_array));
|
|
|
|
|
|
2016-01-18 23:20:49 +00:00
|
|
|
argc = parse_options(argc, argv, prefix, options, ls_remote_usage,
|
|
|
|
|
PARSE_OPT_STOP_AT_NON_OPTION);
|
|
|
|
|
dest = argv[0];
|
2005-07-24 00:54:03 +00:00
|
|
|
|
2021-08-23 13:17:49 +00:00
|
|
|
packet_trace_identity("ls-remote");
|
|
|
|
|
|
2016-01-18 23:20:49 +00:00
|
|
|
if (argc > 1) {
|
|
|
|
|
int i;
|
2021-03-13 16:17:22 +00:00
|
|
|
CALLOC_ARRAY(pattern, argc);
|
2018-03-15 17:31:24 +00:00
|
|
|
for (i = 1; i < argc; i++) {
|
2016-01-18 23:20:49 +00:00
|
|
|
pattern[i - 1] = xstrfmt("*/%s", argv[i]);
|
2018-03-15 17:31:24 +00:00
|
|
|
}
|
2005-07-24 00:54:03 +00:00
|
|
|
}
|
Improve git-peek-remote
This makes git-peek-remote able to basically do everything that
git-ls-remote does (but obviously just for the native protocol, so no
http[s]: or rsync: support).
The default behaviour is the same, but you can now give a mixture of
"--refs", "--tags" and "--heads" flags, where "--refs" forces
git-peek-remote to only show real refs (ie none of the fakey tag lookups,
but also not the special pseudo-refs like HEAD and MERGE_HEAD).
The "--tags" and "--heads" flags respectively limit the output to just
regular tags and heads, of course.
You can still also ask to limit them by name too.
You can combine the flags, so
git peek-remote --refs --tags .
will show all local _true_ tags, without the generated tag lookups
(compare the output without the "--refs" flag).
And "--tags --heads" will show both tags and heads, but will avoid (for
example) any special refs outside of the standard locations.
I'm also planning on adding a "--ignore-local" flag that allows us to ask
it to ignore any refs that we already have in the local tree, but that's
an independent thing.
All this is obviously gearing up to making "git fetch" cheaper.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-04 19:29:10 +00:00
|
|
|
|
2018-10-31 04:24:42 +00:00
|
|
|
if (flags & REF_TAGS)
|
2021-02-05 20:48:48 +00:00
|
|
|
strvec_push(&transport_options.ref_prefixes, "refs/tags/");
|
2018-10-31 04:24:42 +00:00
|
|
|
if (flags & REF_HEADS)
|
2021-02-05 20:48:48 +00:00
|
|
|
strvec_push(&transport_options.ref_prefixes, "refs/heads/");
|
2018-10-31 04:24:42 +00:00
|
|
|
|
2009-11-04 02:38:51 +00:00
|
|
|
remote = remote_get(dest);
|
ls-remote: fall-back to default remotes when no remote specified
Instead of breaking execution when no remote (as specified in the
variable dest) is specified when git-ls-remote is invoked, continue on
and let remote_get() handle it.
This way, we are able to use the default remotes (eg. "origin",
branch.<name>.remote), as git-fetch, git-push, and other users of
remote_get(), do.
If no suitable remote is found, exit with a message describing the
issue, instead of just the usage text, as we do previously.
Add several tests to check that git-ls-remote handles the
no-remote-specified situation.
Also add a test that "git ls-remote <pattern>" does not work; we are
unable to guess the remote in that situation, as are git-fetch and
git-push.
In that test, we are testing for messages coming from two separate
processes, but we should be OK, because the second message is triggered
by closing the fd which must happen after the first message is printed.
(analysis by Jeff King.)
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-08 17:21:13 +00:00
|
|
|
if (!remote) {
|
|
|
|
|
if (dest)
|
|
|
|
|
die("bad repository '%s'", dest);
|
|
|
|
|
die("No remote configured to list refs from.");
|
|
|
|
|
}
|
2009-11-04 02:38:51 +00:00
|
|
|
if (!remote->url_nr)
|
2007-11-07 01:29:20 +00:00
|
|
|
die("remote %s has no configured URL", dest);
|
2011-03-01 09:21:36 +00:00
|
|
|
|
|
|
|
|
if (get_url) {
|
|
|
|
|
printf("%s\n", *remote->url);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2009-11-18 01:42:22 +00:00
|
|
|
transport = transport_get(remote, NULL);
|
2022-05-02 16:50:37 +00:00
|
|
|
if (uploadpack)
|
2007-10-30 01:05:43 +00:00
|
|
|
transport_set_option(transport, TRANS_OPT_UPLOADPACK, uploadpack);
|
2018-04-23 22:46:23 +00:00
|
|
|
if (server_options.nr)
|
|
|
|
|
transport->server_options = &server_options;
|
2007-10-30 01:05:43 +00:00
|
|
|
|
2021-02-05 20:48:48 +00:00
|
|
|
ref = transport_get_remote_refs(transport, &transport_options);
|
builtin/ls-remote: initialize repository based on fetch
ls-remote may or may not operate within a repository, and as such will
not have been initialized with the repository's hash algorithm. Even if
it were, the remote side could be using a different algorithm and we
would still want to display those refs properly. Find the hash
algorithm used by the remote side by querying the transport object and
set our hash algorithm accordingly.
Without this change, if the remote side is using SHA-256, we truncate
the refs to 40 hex characters, since that's the length of the default
hash algorithm (SHA-1).
Note that technically this is not a correct setting of the repository
hash algorithm since, if we are in a repository, it might be one of a
different hash algorithm from the remote side. However, our current
code paths don't handle multiple algorithms and won't for some time, so
this is the best we can do. We rely on the fact that ls-remote never
modifies the current repository, which is a reasonable assumption to
make.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-25 19:59:19 +00:00
|
|
|
if (ref) {
|
|
|
|
|
int hash_algo = hash_algo_by_ptr(transport_get_hash_algo(transport));
|
|
|
|
|
repo_set_hash_algo(the_repository, hash_algo);
|
|
|
|
|
}
|
2010-05-11 17:20:23 +00:00
|
|
|
|
|
|
|
|
if (!dest && !quiet)
|
|
|
|
|
fprintf(stderr, "From %s\n", *remote->url);
|
2007-12-09 06:52:59 +00:00
|
|
|
for ( ; ref; ref = ref->next) {
|
2018-04-09 01:42:26 +00:00
|
|
|
struct ref_array_item *item;
|
2007-12-09 06:52:59 +00:00
|
|
|
if (!check_ref_type(ref, flags))
|
|
|
|
|
continue;
|
|
|
|
|
if (!tail_match(pattern, ref->name))
|
|
|
|
|
continue;
|
2018-04-09 01:42:26 +00:00
|
|
|
item = ref_array_push(&ref_array, ref->name, &ref->old_oid);
|
|
|
|
|
item->symref = xstrdup_or_null(ref->symref);
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
sorting = ref_sorting_options(&sorting_options);
|
|
|
|
|
ref_array_sort(sorting, &ref_array);
|
2018-04-09 01:42:26 +00:00
|
|
|
|
|
|
|
|
for (i = 0; i < ref_array.nr; i++) {
|
|
|
|
|
const struct ref_array_item *ref = ref_array.items[i];
|
2016-01-18 23:20:50 +00:00
|
|
|
if (show_symref_target && ref->symref)
|
2018-04-09 01:42:26 +00:00
|
|
|
printf("ref: %s\t%s\n", ref->symref, ref->refname);
|
|
|
|
|
printf("%s\t%s\n", oid_to_hex(&ref->objectname), ref->refname);
|
2011-05-18 20:06:00 +00:00
|
|
|
status = 0; /* we found something */
|
2007-10-30 01:05:43 +00:00
|
|
|
}
|
2018-04-09 01:42:26 +00:00
|
|
|
|
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
|
|
|
ref_sorting_release(sorting);
|
2018-10-18 07:28:54 +00:00
|
|
|
ref_array_clear(&ref_array);
|
2021-03-21 16:58:37 +00:00
|
|
|
if (transport_disconnect(transport))
|
2022-02-05 00:08:14 +00:00
|
|
|
status = 1;
|
|
|
|
|
transport_ls_refs_options_release(&transport_options);
|
2011-05-18 20:06:00 +00:00
|
|
|
return status;
|
2005-07-24 00:54:03 +00:00
|
|
|
}
|