All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
Subject: [PATCH 3/9] list-objects: drop process_gitlink() function
Date: Tue, 13 Dec 2022 06:12:09 -0500	[thread overview]
Message-ID: <Y5heCZ7uak1kymiV@coredump.intra.peff.net> (raw)
In-Reply-To: <Y5hdvpbLpXySHFRz@coredump.intra.peff.net>

Our object graph traversal code has a process_gitlink() function which
we call when we see a gitlink entry. The function does nothing; it was
added in the early days of gitlinks by 6e2f441bd4 (Teach git
list-objects logic to not follow gitlinks, 2007-04-13).

The comment above the function talks about some things we _could_ do.
But in the intervening 15 years, nobody has touched the function, and
the submodule code usually makes its own decisions about when and how to
examine the links. At the generic traversal layer, we can't assume that
the pointed-to commit is available.

Let's drop this placeholder that isn't really helping anything. This
silences some -Wunused-parameter warnings, and also gets rid of a crufty
use of "const unsigned char *" to pass a raw hash value.

Signed-off-by: Jeff King <peff@peff.net>
---
 list-objects.c | 33 +--------------------------------
 1 file changed, 1 insertion(+), 32 deletions(-)

diff --git a/list-objects.c b/list-objects.c
index 250d9de41c..7528fe1db2 100644
--- a/list-objects.c
+++ b/list-objects.c
@@ -81,36 +81,6 @@ static void process_blob(struct traversal_context *ctx,
 	strbuf_setlen(path, pathlen);
 }
 
-/*
- * Processing a gitlink entry currently does nothing, since
- * we do not recurse into the subproject.
- *
- * We *could* eventually add a flag that actually does that,
- * which would involve:
- *  - is the subproject actually checked out?
- *  - if so, see if the subproject has already been added
- *    to the alternates list, and add it if not.
- *  - process the commit (or tag) the gitlink points to
- *    recursively.
- *
- * However, it's unclear whether there is really ever any
- * reason to see superprojects and subprojects as such a
- * "unified" object pool (potentially resulting in a totally
- * humongous pack - avoiding which was the whole point of
- * having gitlinks in the first place!).
- *
- * So for now, there is just a note that we *could* follow
- * the link, and how to do it. Whether it necessarily makes
- * any sense what-so-ever to ever do that is another issue.
- */
-static void process_gitlink(struct traversal_context *ctx,
-			    const unsigned char *sha1,
-			    struct strbuf *path,
-			    const char *name)
-{
-	/* Nothing to do */
-}
-
 static void process_tree(struct traversal_context *ctx,
 			 struct tree *tree,
 			 struct strbuf *base,
@@ -149,8 +119,7 @@ static void process_tree_contents(struct traversal_context *ctx,
 			process_tree(ctx, t, base, entry.path);
 		}
 		else if (S_ISGITLINK(entry.mode))
-			process_gitlink(ctx, entry.oid.hash,
-					base, entry.path);
+			; /* ignore gitlink */
 		else {
 			struct blob *b = lookup_blob(ctx->revs->repo, &entry.oid);
 			if (!b) {
-- 
2.39.0.546.g5ea984bc66


  parent reply	other threads:[~2022-12-13 11:13 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 ` [PATCH 1/9] ls-refs: use repository parameter to iterate refs Jeff King
2022-12-13 11:11 ` [PATCH 2/9] blob: drop unused parts of parse_blob_buffer() Jeff King
2022-12-13 11:12 ` Jeff King [this message]
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=Y5heCZ7uak1kymiV@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.