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

Reply via email to