2007-10-30 09:05:43 +08:00
|
|
|
#include "builtin.h"
|
2005-07-24 08:54:03 +08:00
|
|
|
#include "cache.h"
|
2007-10-30 09:05:43 +08:00
|
|
|
#include "transport.h"
|
2018-04-09 09:42:26 +08:00
|
|
|
#include "ref-filter.h"
|
2007-10-30 09:05:43 +08:00
|
|
|
#include "remote.h"
|
2018-03-16 01:31:24 +08:00
|
|
|
#include "refs.h"
|
2005-07-24 08:54:03 +08:00
|
|
|
|
2016-01-19 07:20:49 +08:00
|
|
|
static const char * const ls_remote_usage[] = {
|
|
|
|
|
N_("git ls-remote [--heads] [--tags] [--refs] [--upload-pack=<exec>]\n"
|
2022-10-13 23:39:13 +08:00
|
|
|
" [-q | --quiet] [--exit-code] [--get-url] [--sort=<key>]\n"
|
2023-02-11 12:52:56 +08:00
|
|
|
" [--symref] [<repository> [<patterns>...]]"),
|
2016-01-19 07:20:49 +08:00
|
|
|
NULL
|
|
|
|
|
};
|
2005-07-24 08:54:03 +08:00
|
|
|
|
2007-12-09 14:52:59 +08:00
|
|
|
/*
|
2007-12-10 04:16:55 +08:00
|
|
|
* Is there one among the list of patterns that match the tail part
|
|
|
|
|
* of the path?
|
2007-12-09 14:52:59 +08:00
|
|
|
*/
|
|
|
|
|
static int tail_match(const char **pattern, const char *path)
|
|
|
|
|
{
|
|
|
|
|
const char *p;
|
2017-03-29 03:46:30 +08:00
|
|
|
char *pathbuf;
|
2007-12-09 14:52:59 +08:00
|
|
|
|
2007-12-10 04:16:55 +08:00
|
|
|
if (!pattern)
|
2007-12-09 14:52:59 +08:00
|
|
|
return 1; /* no restriction */
|
|
|
|
|
|
2017-03-29 03:46:30 +08:00
|
|
|
pathbuf = xstrfmt("/%s", path);
|
2007-12-10 04:16:55 +08:00
|
|
|
while ((p = *(pattern++)) != NULL) {
|
2017-06-23 05:38:08 +08:00
|
|
|
if (!wildmatch(p, pathbuf, 0)) {
|
2017-03-29 03:46:30 +08:00
|
|
|
free(pathbuf);
|
2007-12-10 04:16:55 +08:00
|
|
|
return 1;
|
2017-03-29 03:46:30 +08:00
|
|
|
}
|
2007-12-09 14:52:59 +08:00
|
|
|
}
|
2017-03-29 03:46:30 +08:00
|
|
|
free(pathbuf);
|
2007-12-09 14:52:59 +08:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2007-11-05 04:51:17 +08:00
|
|
|
int cmd_ls_remote(int argc, const char **argv, const char *prefix)
|
2005-07-24 08:54:03 +08:00
|
|
|
{
|
2007-10-30 09:05:43 +08: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-05 03:29:10 +08:00
|
|
|
unsigned flags = 0;
|
2011-03-01 17:21:36 +08:00
|
|
|
int get_url = 0;
|
2010-05-12 01:20:23 +08:00
|
|
|
int quiet = 0;
|
2011-05-19 04:06:00 +08:00
|
|
|
int status = 0;
|
2016-01-19 07:20:50 +08:00
|
|
|
int show_symref_target = 0;
|
2007-10-30 09:05:43 +08:00
|
|
|
const char *uploadpack = NULL;
|
2007-12-09 14:52:59 +08:00
|
|
|
const char **pattern = NULL;
|
2021-02-06 04:48:48 +08:00
|
|
|
struct transport_ls_refs_options transport_options =
|
|
|
|
|
TRANSPORT_LS_REFS_OPTIONS_INIT;
|
2018-04-09 09:42:26 +08:00
|
|
|
int i;
|
2018-04-24 06:46:23 +08:00
|
|
|
struct string_list server_options = STRING_LIST_INIT_DUP;
|
2007-10-30 09:05:43 +08:00
|
|
|
|
2007-11-07 09:29:20 +08:00
|
|
|
struct remote *remote;
|
2007-10-30 09:05:43 +08:00
|
|
|
struct transport *transport;
|
|
|
|
|
const struct ref *ref;
|
2018-04-09 09:42:26 +08:00
|
|
|
struct ref_array ref_array;
|
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-21 03:23:53 +08:00
|
|
|
struct string_list sorting_options = STRING_LIST_INIT_DUP;
|
2005-11-26 15:50:21 +08:00
|
|
|
|
2016-01-19 07:20:49 +08: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-21 03:23:53 +08:00
|
|
|
OPT_REF_SORT(&sorting_options),
|
2018-02-09 19:02:03 +08: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-19 07:20:50 +08:00
|
|
|
OPT_BOOL(0, "symref", &show_symref_target,
|
|
|
|
|
N_("show underlying ref in addition to the object pointed by it")),
|
2018-04-24 06:46:23 +08:00
|
|
|
OPT_STRING_LIST('o', "server-option", &server_options, N_("server-specific"), N_("option to transmit")),
|
2016-01-19 07:20:49 +08:00
|
|
|
OPT_END()
|
|
|
|
|
};
|
2011-09-17 02:14:27 +08:00
|
|
|
|
2018-04-09 09:42:26 +08:00
|
|
|
memset(&ref_array, 0, sizeof(ref_array));
|
|
|
|
|
|
2016-01-19 07:20:49 +08:00
|
|
|
argc = parse_options(argc, argv, prefix, options, ls_remote_usage,
|
|
|
|
|
PARSE_OPT_STOP_AT_NON_OPTION);
|
|
|
|
|
dest = argv[0];
|
2005-07-24 08:54:03 +08:00
|
|
|
|
2021-08-23 21:17:49 +08:00
|
|
|
packet_trace_identity("ls-remote");
|
|
|
|
|
|
2016-01-19 07:20:49 +08:00
|
|
|
if (argc > 1) {
|
|
|
|
|
int i;
|
2021-03-14 00:17:22 +08:00
|
|
|
CALLOC_ARRAY(pattern, argc);
|
2018-03-16 01:31:24 +08:00
|
|
|
for (i = 1; i < argc; i++) {
|
2016-01-19 07:20:49 +08:00
|
|
|
pattern[i - 1] = xstrfmt("*/%s", argv[i]);
|
2018-03-16 01:31:24 +08:00
|
|
|
}
|
2005-07-24 08:54:03 +08: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-05 03:29:10 +08:00
|
|
|
|
2018-10-31 12:24:42 +08:00
|
|
|
if (flags & REF_TAGS)
|
2021-02-06 04:48:48 +08:00
|
|
|
strvec_push(&transport_options.ref_prefixes, "refs/tags/");
|
2018-10-31 12:24:42 +08:00
|
|
|
if (flags & REF_HEADS)
|
2021-02-06 04:48:48 +08:00
|
|
|
strvec_push(&transport_options.ref_prefixes, "refs/heads/");
|
2018-10-31 12:24:42 +08:00
|
|
|
|
2009-11-04 10:38:51 +08: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-09 01:21:13 +08:00
|
|
|
if (!remote) {
|
|
|
|
|
if (dest)
|
|
|
|
|
die("bad repository '%s'", dest);
|
|
|
|
|
die("No remote configured to list refs from.");
|
|
|
|
|
}
|
2009-11-04 10:38:51 +08:00
|
|
|
if (!remote->url_nr)
|
2007-11-07 09:29:20 +08:00
|
|
|
die("remote %s has no configured URL", dest);
|
2011-03-01 17:21:36 +08:00
|
|
|
|
|
|
|
|
if (get_url) {
|
|
|
|
|
printf("%s\n", *remote->url);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2009-11-18 09:42:22 +08:00
|
|
|
transport = transport_get(remote, NULL);
|
2022-05-03 00:50:37 +08:00
|
|
|
if (uploadpack)
|
2007-10-30 09:05:43 +08:00
|
|
|
transport_set_option(transport, TRANS_OPT_UPLOADPACK, uploadpack);
|
2018-04-24 06:46:23 +08:00
|
|
|
if (server_options.nr)
|
|
|
|
|
transport->server_options = &server_options;
|
2007-10-30 09:05:43 +08:00
|
|
|
|
2021-02-06 04:48:48 +08: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-26 03:59:19 +08: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-12 01:20:23 +08:00
|
|
|
|
|
|
|
|
if (!dest && !quiet)
|
|
|
|
|
fprintf(stderr, "From %s\n", *remote->url);
|
2007-12-09 14:52:59 +08:00
|
|
|
for ( ; ref; ref = ref->next) {
|
2018-04-09 09:42:26 +08:00
|
|
|
struct ref_array_item *item;
|
2007-12-09 14:52:59 +08:00
|
|
|
if (!check_ref_type(ref, flags))
|
|
|
|
|
continue;
|
|
|
|
|
if (!tail_match(pattern, ref->name))
|
|
|
|
|
continue;
|
2018-04-09 09:42:26 +08:00
|
|
|
item = ref_array_push(&ref_array, ref->name, &ref->old_oid);
|
|
|
|
|
item->symref = xstrdup_or_null(ref->symref);
|
|
|
|
|
}
|
|
|
|
|
|
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-21 03:23:53 +08:00
|
|
|
if (sorting_options.nr) {
|
|
|
|
|
struct ref_sorting *sorting;
|
|
|
|
|
|
|
|
|
|
sorting = ref_sorting_options(&sorting_options);
|
2018-04-09 09:42:26 +08:00
|
|
|
ref_array_sort(sorting, &ref_array);
|
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-21 03:23:53 +08:00
|
|
|
ref_sorting_release(sorting);
|
|
|
|
|
}
|
2018-04-09 09:42:26 +08:00
|
|
|
|
|
|
|
|
for (i = 0; i < ref_array.nr; i++) {
|
|
|
|
|
const struct ref_array_item *ref = ref_array.items[i];
|
2016-01-19 07:20:50 +08:00
|
|
|
if (show_symref_target && ref->symref)
|
2018-04-09 09:42:26 +08: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-19 04:06:00 +08:00
|
|
|
status = 0; /* we found something */
|
2007-10-30 09:05:43 +08:00
|
|
|
}
|
2018-04-09 09:42:26 +08:00
|
|
|
|
2018-10-18 15:28:54 +08:00
|
|
|
ref_array_clear(&ref_array);
|
2021-03-22 00:58:37 +08:00
|
|
|
if (transport_disconnect(transport))
|
2022-02-05 08:08:14 +08:00
|
|
|
status = 1;
|
|
|
|
|
transport_ls_refs_options_release(&transport_options);
|
2011-05-19 04:06:00 +08:00
|
|
|
return status;
|
2005-07-24 08:54:03 +08:00
|
|
|
}
|
