Re: [PATCH v4 17/35] ls-remote: pass ref patterns when requesting a remote's refs
From: Junio C Hamano <hidden>
Date: 2018-03-02 22:14:04
Brandon Williams [off-list ref] writes:
quoted hunk
Construct an argv_array of the ref patterns supplied via the command line and pass them to 'transport_get_remote_refs()' to be used when communicating protocol v2 so that the server can limit the ref advertisement based on the supplied patterns. Signed-off-by: Brandon Williams <redacted> --- builtin/ls-remote.c | 12 ++++++++++-- refs.c | 14 ++++++++++++++ refs.h | 7 +++++++ t/t5702-protocol-v2.sh | 26 ++++++++++++++++++++++++++ 4 files changed, 57 insertions(+), 2 deletions(-)diff --git a/builtin/ls-remote.c b/builtin/ls-remote.c index c6e9847c5..083ba8b29 100644 --- a/builtin/ls-remote.c +++ b/builtin/ls-remote.c@@ -2,6 +2,7 @@ #include "cache.h" #include "transport.h" #include "remote.h" +#include "refs.h" static const char * const ls_remote_usage[] = { N_("git ls-remote [--heads] [--tags] [--refs] [--upload-pack=<exec>]\n"@@ -43,6 +44,7 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix) int show_symref_target = 0; const char *uploadpack = NULL; const char **pattern = NULL; + struct argv_array ref_patterns = ARGV_ARRAY_INIT; struct remote *remote; struct transport *transport;@@ -74,8 +76,14 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix) if (argc > 1) { int i; pattern = xcalloc(argc, sizeof(const char *)); - for (i = 1; i < argc; i++) + for (i = 1; i < argc; i++) { pattern[i - 1] = xstrfmt("*/%s", argv[i]); + + if (strchr(argv[i], '*')) + argv_array_push(&ref_patterns, argv[i]); + else + expand_ref_pattern(&ref_patterns, argv[i]); + } } remote = remote_get(dest);@@ -96,7 +104,7 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix) if (uploadpack != NULL) transport_set_option(transport, TRANS_OPT_UPLOADPACK, uploadpack); - ref = transport_get_remote_refs(transport, NULL); + ref = transport_get_remote_refs(transport, &ref_patterns);
Yup, this is a logical and an obvious conclusion of the past handful of steps ;-) I actually was wondering why the previous step didn't do this already, but the resulting series is easier to understand if this is kept as a separate step. However, this also means that traditional pattern language ls-remote used to support dictates what ls-refs command over the wire can take, which may not be optimal.