This limit was added in
0ebde32 (Add 'resolve_gitlink_ref()' helper function - 2007-04-09)
Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu>
---
Theoretically, somebody else might be relying on
resolve_gitlink_ref_recursive() to fail for too-long reference names
to prevent path.c's pitiful error handling from returning "/bad-path/"
and causing a nonsensical file lookup. I doubt it, but if somebody is
worried about it we could leave out this patch and instead build the
MAXREFLEN check into parse_ref().
Long-term, I think we should fix up path.c to remove its PATH_MAX
limits. I've started working on that.
refs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/refs.c b/refs.c
index 9f2a0f8..e1aa6a4 100644
--- a/refs.c
+++ b/refs.c
@@ -1279,7 +1279,6 @@ static struct ref_dir *get_loose_refs(struct ref_cache
*refs)
/* We allow "recursive" symbolic refs. Only within reason, though */
#define MAXDEPTH 5
-#define MAXREFLEN (1024)
/*
* Called by resolve_gitlink_ref_recursive() after it failed to read
@@ -1308,7 +1307,7 @@ static int resolve_gitlink_ref_recursive(struct ref_cache
*refs,
char buffer[128], *p;
char *path;
- if (recursion > MAXDEPTH || strlen(refname) > MAXREFLEN)
+ if (recursion > MAXDEPTH)
return -1;
path = *refs->name
? git_path_submodule(refs->name, "%s", refname)
--
2.1.1
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
