All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
Subject: [PATCH 1/9] ls-refs: use repository parameter to iterate refs
Date: Tue, 13 Dec 2022 06:11:10 -0500	[thread overview]
Message-ID: <Y5hdzjlboJrsnvKK@coredump.intra.peff.net> (raw)
In-Reply-To: <Y5hdvpbLpXySHFRz@coredump.intra.peff.net>

The ls_refs() function (for the v2 protocol command of the same name)
takes a repository parameter (like all v2 commands), but ignores it. It
should use it to access the refs.

This isn't a bug in practice, since we only call this function when
serving upload-pack from the main repository. But it's an awkward
gotcha, and it causes -Wunused-parameter to complain.

The main reason we don't use the repository parameter is that the ref
iteration interface we call doesn't have a "refs_" variant that takes a
ref_store. However we can easily add one. In fact, since there is only
one other caller (in ref-filter.c), there is no need to maintain the
non-repository wrapper; that caller can just use the_repository. It's
still a long way from consistently using a repository object, but it's
one small step in the right direction.

Signed-off-by: Jeff King <peff@peff.net>
---
 ls-refs.c    | 5 +++--
 ref-filter.c | 5 +++--
 refs.c       | 9 +++++----
 refs.h       | 6 ++++--
 4 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/ls-refs.c b/ls-refs.c
index fb6769742c..697d4beb8d 100644
--- a/ls-refs.c
+++ b/ls-refs.c
@@ -194,8 +194,9 @@ int ls_refs(struct repository *r, struct packet_reader *request)
 	send_possibly_unborn_head(&data);
 	if (!data.prefixes.nr)
 		strvec_push(&data.prefixes, "");
-	for_each_fullref_in_prefixes(get_git_namespace(), data.prefixes.v,
-				     send_ref, &data);
+	refs_for_each_fullref_in_prefixes(get_main_ref_store(r),
+					  get_git_namespace(), data.prefixes.v,
+					  send_ref, &data);
 	packet_fflush(stdout);
 	strvec_clear(&data.prefixes);
 	strbuf_release(&data.buf);
diff --git a/ref-filter.c b/ref-filter.c
index 9dc2cd1451..971303683b 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -2128,8 +2128,9 @@ static int for_each_fullref_in_pattern(struct ref_filter *filter,
 		return for_each_fullref_in("", cb, cb_data);
 	}
 
-	return for_each_fullref_in_prefixes(NULL, filter->name_patterns,
-					    cb, cb_data);
+	return refs_for_each_fullref_in_prefixes(get_main_ref_store(the_repository),
+						 NULL, filter->name_patterns,
+						 cb, cb_data);
 }
 
 /*
diff --git a/refs.c b/refs.c
index 2c7e88b190..e31dbcda59 100644
--- a/refs.c
+++ b/refs.c
@@ -1723,9 +1723,10 @@ static void find_longest_prefixes(struct string_list *out,
 	strbuf_release(&prefix);
 }
 
-int for_each_fullref_in_prefixes(const char *namespace,
-				 const char **patterns,
-				 each_ref_fn fn, void *cb_data)
+int refs_for_each_fullref_in_prefixes(struct ref_store *ref_store,
+				      const char *namespace,
+				      const char **patterns,
+				      each_ref_fn fn, void *cb_data)
 {
 	struct string_list prefixes = STRING_LIST_INIT_DUP;
 	struct string_list_item *prefix;
@@ -1740,7 +1741,7 @@ int for_each_fullref_in_prefixes(const char *namespace,
 
 	for_each_string_list_item(prefix, &prefixes) {
 		strbuf_addstr(&buf, prefix->string);
-		ret = for_each_fullref_in(buf.buf, fn, cb_data);
+		ret = refs_for_each_fullref_in(ref_store, buf.buf, fn, cb_data);
 		if (ret)
 			break;
 		strbuf_setlen(&buf, namespace_len);
diff --git a/refs.h b/refs.h
index 3266fd8f57..935cdd1ece 100644
--- a/refs.h
+++ b/refs.h
@@ -354,8 +354,10 @@ int for_each_fullref_in(const char *prefix, each_ref_fn fn, void *cb_data);
  *
  * callers should be prepared to ignore references that they did not ask for.
  */
-int for_each_fullref_in_prefixes(const char *namespace, const char **patterns,
-				 each_ref_fn fn, void *cb_data);
+int refs_for_each_fullref_in_prefixes(struct ref_store *refs,
+				      const char *namespace, const char **patterns,
+				      each_ref_fn fn, void *cb_data);
+
 /**
  * iterate refs from the respective area.
  */
-- 
2.39.0.546.g5ea984bc66


  reply	other threads:[~2022-12-13 11:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-13 11:10 [PATCH 0/9] more -Wunused-parameter fixes/annotations Jeff King
2022-12-13 11:11 ` Jeff King [this message]
2022-12-13 11:11 ` [PATCH 2/9] blob: drop unused parts of parse_blob_buffer() Jeff King
2022-12-13 11:12 ` [PATCH 3/9] list-objects: drop process_gitlink() function Jeff King
2022-12-13 11:12 ` [PATCH 4/9] ws: drop unused parameter from ws_blank_line() Jeff King
2022-12-13 11:13 ` [PATCH 5/9] xdiff: drop unused parameter in def_ff() Jeff King
2022-12-13 11:13 ` [PATCH 6/9] xdiff: mark unused parameter in xdl_call_hunk_func() Jeff King
2022-12-13 11:13 ` [PATCH 7/9] diff: mark unused parameters in callbacks Jeff King
2022-12-13 11:14 ` [PATCH 8/9] list-objects-filter: mark unused parameters in virtual functions Jeff King
2022-12-13 11:16 ` [PATCH 9/9] userdiff: mark unused parameter in internal callback Jeff King
2022-12-14  1:38 ` [PATCH 0/9] more -Wunused-parameter fixes/annotations Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y5hdzjlboJrsnvKK@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.