summaryrefslogtreecommitdiff
path: root/sha1_name.c
AgeCommit message (Collapse)Author
2005-10-04Make sure get_sha1 does not accept ambiguous sha1 prefix (again).Junio C Hamano
The earlier fix incorrectly dropped the code the original had to ensure the found SHA1 is at least unique within the same pack. Restore the check. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-03Error message from get_sha1() on ambiguous short SHA1.Junio C Hamano
Unlike cases where "no such object exists", the case where specified prefix is ambiguous would confuse the user if we say "no such commit" or such. Give an extra error message from the uniqueness check if there are more than one objects that match the given prefix. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-03Make sure get_sha1 does not accept ambiguous sha1 prefix.Junio C Hamano
The original code did not even check alternates, and was confused if an unpacked object was uniquely found when there was another object that shares the same prefix in the pack. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-02[PATCH] Allow reading "symbolic refs" that point to other refsLinus Torvalds
This extends the ref reading to understand a "symbolic ref": a ref file that starts with "ref: " and points to another ref file, and thus introduces the notion of ref aliases. This is in preparation of allowing HEAD to eventually not be a symlink, but one of these symbolic refs instead. [jc: Linus originally required the prefix to be "ref: " five bytes and nothing else, but I changed it to allow and strip any number of leading whitespaces to match what update-ref.c does.] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-20Fix extended short SHA1 name completionLinus Torvalds
get_sha1() would not do sha1 completion of short SHA1's when they were part of a more complex expression. So doing git-rev-parse 727132834e6be48a93c1bd6458a29d474ce7d5d5^ would work, and return 87c6aeb4efdd4355918d127a91bd0adc5a02f8ff. But using the shorthand version git-rev-list 72713^ wouldn't work. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-23[PATCH] Add a new extended SHA1 syntax <name>~<num>Junio C Hamano
The new notation is a short-hand for <name> followed by <num> caret ('^') characters. E.g. "master~4" is the fourth generation ancestor of the current "master" branch head, following the first parents; same as "master^^^^" but a bit more readable. This will be used in the updated "git show-branch" command. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21[PATCH] sha1_name: do not accept .git/refs/snap/.Junio C Hamano
I think Linus did a cut & paste from an early JIT code while developing the current extended SHA1 notation, and left it there as a courtesy, but the directory does not deserve to be treated any more specially than, say, .git/refs/bisect. If the subdirectories under .git/refs proliferate, we may want to switch to scanning that hierarchy at runtime, instead of the current hard-coded set, although I think that would be overkill. Signed-off-by: Junio C Hamano <junkio@cox.net> From nobody Mon Sep 17 00:00:00 2001 Subject: [PATCH] Add a new extended SHA1 syntax <name>:<num> From: Junio C Hamano <junkio@cox.net> Date: 1124617434 -0700 The new notation is a short-hand for <name> followed by <num> caret ('^') characters. E.g. "master:4" is the fourth generation ancestor of the current "master" branch head, following the first parents; same as "master^^^^" but a bit more readable. This will be used in the updated "git show-branch" command. Signed-off-by: Junio C Hamano <junkio@cox.net> --- sha1_name.c | 41 +++++++++++++++++++++++++++++++++++++++++ 1 files changed, 41 insertions(+), 0 deletions(-) d5098ce769da46df6d45dc8f41b06dd758fdaea7 diff --git a/sha1_name.c b/sha1_name.c --- a/sha1_name.c +++ b/sha1_name.c @@ -191,9 +191,29 @@ static int get_parent(const char *name, return -1; } +static int get_nth_ancestor(const char *name, int len, + unsigned char *result, int generation) +{ + unsigned char sha1[20]; + int ret = get_sha1_1(name, len, sha1); + if (ret) + return ret; + + while (generation--) { + struct commit *commit = lookup_commit_reference(sha1); + + if (!commit || parse_commit(commit) || !commit->parents) + return -1; + memcpy(sha1, commit->parents->item->object.sha1, 20); + } + memcpy(result, sha1, 20); + return 0; +} + static int get_sha1_1(const char *name, int len, unsigned char *sha1) { int parent, ret; + const char *cp; /* foo^[0-9] or foo^ (== foo^1); we do not do more than 9 parents. */ if (len > 2 && name[len-2] == '^' && @@ -210,6 +230,27 @@ static int get_sha1_1(const char *name, if (parent >= 0) return get_parent(name, len, sha1, parent); + /* name:3 is name^^^, + * name:12 is name^^^^^^^^^^^^, and + * name: is name + */ + parent = 0; + for (cp = name + len - 1; name <= cp; cp--) { + int ch = *cp; + if ('0' <= ch && ch <= '9') + continue; + if (ch != ':') + parent = -1; + break; + } + if (!parent && *cp == ':') { + int len1 = cp - name; + cp++; + while (cp < name + len) + parent = parent * 10 + *cp++ - '0'; + return get_nth_ancestor(name, len1, sha1, parent); + } + ret = get_sha1_basic(name, len, sha1); if (!ret) return 0;
2005-08-14[PATCH] Make get_sha1_basic() more carefulLinus Torvalds
The "get_sha1_hex()" function is designed to work with SHA1 hex strings that may be followed by arbitrary crud. However, that's not acceptable for "get_sha1()" which is used for command line arguments etc: we don't want to silently allow random characters after the end of the SHA1. So verify that the hex string is all we have. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-14[PATCH] Make sure git-resolve-script always works on commitsLinus Torvalds
You can resolve a tag, and it does the right thing except that it might end up writing the tag itself into the resulting HEAD, which will confuse subsequent operations no end. This makes sure that when we resolve two heads, we will have turned them into proper commits before we start acting on them. This also fixes the parsing of "treeish^0", which would incorrectly resolve to "treeish" instead of causing an error. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-10[PATCH] Fix git-rev-parse's parent handlingJohannes Schindelin
git-rev-parse HEAD^1 would fail, because of an off-by-one bug (but HEAD^ would yield the expected result). Also, when the parent does not exist, do not silently return an incorrect SHA1. Of course, this no longer applies to git-rev-parse alone, but every user of get_sha1(). While at it, add a test. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-05Update get_sha1() to grok extended format.Junio C Hamano
Everybody envies rev-parse, who is the only one that can grok the extended sha1 format. Move the get_extended_sha1() out of rev-parse, rename it to get_sha1() and make it available to everybody else. The one I posted earlier to the list had one bug where it did not handle a name that ends with a digit correctly (it incorrectly tried the "Nth parent" path). This commit fixes it. Signed-off-by: Junio C Hamano <junkio@cox.net>