Alex RiesenThe patch below reminded me of something:
+ /* We want to allow .git/description file and
+ * "description" branch to exist at the same time.
+ * "git-rev-parse description" should silently skip
+ * .git/description file as a candidate for
+ * get_sha1(). However, having garbage file anywhere
+ * under refs/ is not OK, and we would not have caught
+ * ambiguous heads and tags with the above test.
+ */
+ else if (**p && !access(pathname, F_OK)) {
+ /* Garbage exists under .git/refs */
+ return error("garbage ref found '%s'", pathname);
+ }Maybe we should only allow only a strictly defined set of refnames under $GIT_DIR? The directory is used pretty much for anything else (temporary message files, config, description).
So, if we, say, allow only HEAD, ORIG_HEAD, and MERGE_HEAD to be references in .git/ and ignore everything else. Then there will be no ambiguity anymore and no need to parse "description" or "config" reference (besides, I can very simply imagine a message file containing "ref: refs/heads/foo").
Does it make sense or have I missed some very informative discussion as to why we do allow references to be anywhere in .git?
Subject: [PATCH] The patch below reminded me of something:
+ /* We want to allow .git/description file and
+ * "description" branch to exist at the same time.
+ * "git-rev-parse description" should silently skip
+ * .git/description file as a candidate for
+ * get_sha1(). However, having garbage file anywhere
+ * under refs/ is not OK, and we would not have caught
+ * ambiguous heads and tags with the above test.
+ */
+ else if (**p && !access(pathname, F_OK)) {
+ /* Garbage exists under .git/refs */
+ return error("garbage ref found '%s'", pathname);
+ }Maybe we should only allow only a strictly defined set of refnames under $GIT_DIR? The directory is used pretty much for anything else (temporary message files, config, description).
So, if we, say, allow only HEAD, ORIG_HEAD, and MERGE_HEAD to be references in .git/ and ignore everything else. Then there will be no ambiguity anymore and no need to parse "description" or "config" reference (besides, I can very simply imagine a message file containing "ref: refs/heads/foo").
Does it make sense or have I missed some very informative discussion as to why we do allow references to be anywhere in .git?
---
sha1_name.c | 22 +++++++++++++++++++++- 1 files changed, 21 insertions(+), 1 deletions(-)
4a0ef1ed775d2311da7125257cb734d561fd2ef1
diff --git a/sha1_name.c b/sha1_name.c index bf8f0f0..dce1574 100644 --- a/sha1_name.c +++ b/sha1_name.c @@ -247,7 +247,27 @@ static int get_sha1_basic(const char *st if (ambiguous_path(str, len)) return -1; - for (p = prefix; *p; p++) { + p = prefix; + /* Check references _without_ leading directories */ + if (!memchr(str, '/', len)) { + /* only these references can be directly in $GIT_DIR... */ + static const char *git_refs[] = { + "HEAD", + "ORIG_HEAD", + "FETCH_HEAD", + "MERGE_HEAD", + NULL + }; + const char **r; + for (r = git_refs; *r; ++r) + if (strlen(*r) == len && strncmp(*r, str, len) == 0) + break; + /* ...all the others have to be somewhere under .git/refs/ */ + if ( !*r ) + ++p; + } + + for (; *p; p++) { char *pathname = git_path("%s/%.*s", *p, len, str); if (!read_ref(pathname, sha1)) {
-- 0.99.9.GIT
