Skip to content

Commit 0027148

Browse files
peffgitster
authored andcommitted
list-objects: drop process_gitlink() function
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 6e2f441 (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 <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
1 parent c1166ca commit 0027148

File tree

1 file changed

+1
-32
lines changed

1 file changed

+1
-32
lines changed

list-objects.c

Lines changed: 1 addition & 32 deletions
Original file line numberDiff line numberDiff line change
@@ -81,36 +81,6 @@ static void process_blob(struct traversal_context *ctx,
8181
strbuf_setlen(path, pathlen);
8282
}
8383

84-
/*
85-
* Processing a gitlink entry currently does nothing, since
86-
* we do not recurse into the subproject.
87-
*
88-
* We *could* eventually add a flag that actually does that,
89-
* which would involve:
90-
* - is the subproject actually checked out?
91-
* - if so, see if the subproject has already been added
92-
* to the alternates list, and add it if not.
93-
* - process the commit (or tag) the gitlink points to
94-
* recursively.
95-
*
96-
* However, it's unclear whether there is really ever any
97-
* reason to see superprojects and subprojects as such a
98-
* "unified" object pool (potentially resulting in a totally
99-
* humongous pack - avoiding which was the whole point of
100-
* having gitlinks in the first place!).
101-
*
102-
* So for now, there is just a note that we *could* follow
103-
* the link, and how to do it. Whether it necessarily makes
104-
* any sense what-so-ever to ever do that is another issue.
105-
*/
106-
static void process_gitlink(struct traversal_context *ctx,
107-
const unsigned char *sha1,
108-
struct strbuf *path,
109-
const char *name)
110-
{
111-
/* Nothing to do */
112-
}
113-
11484
static void process_tree(struct traversal_context *ctx,
11585
struct tree *tree,
11686
struct strbuf *base,
@@ -149,8 +119,7 @@ static void process_tree_contents(struct traversal_context *ctx,
149119
process_tree(ctx, t, base, entry.path);
150120
}
151121
else if (S_ISGITLINK(entry.mode))
152-
process_gitlink(ctx, entry.oid.hash,
153-
base, entry.path);
122+
; /* ignore gitlink */
154123
else {
155124
struct blob *b = lookup_blob(ctx->revs->repo, &entry.oid);
156125
if (!b) {

0 commit comments

Comments
 (0)