kernel/git - git - PowerEL Git System

Author	SHA1	Message	Date
Junio C Hamano	4f7599ac25	[PATCH] Add a new extended SHA1 syntax <name>~<num> 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>	20 years ago
Junio C Hamano	1dfcfbce2d	[PATCH] sha1_name: do not accept .git/refs/snap/. 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;	20 years ago
Linus Torvalds	3c3852e33b	[PATCH] Make get_sha1_basic() more careful 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>	20 years ago
Linus Torvalds	02a4a32c2d	[PATCH] Make sure git-resolve-script always works on commits 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>	20 years ago
Johannes Schindelin	ef0bd2e6e6	[PATCH] Fix git-rev-parse's parent handling 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>	20 years ago
Junio C Hamano	9938af6a85	Update get_sha1() to grok extended format. 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>	20 years ago

1 2