Граф коммитов

108 Коммитов

Автор SHA1 Сообщение Дата
Linus Torvalds ca8db1424d [PATCH] Allow reading "symbolic refs" that point to other refs
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-10-01 23:19:32 -07:00
Linus Torvalds af61c6e008 Fix extended short SHA1 name completion
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 87c6aeb4ef. 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-09-20 15:04:19 -07:00
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>
2005-08-22 18:34:09 -07:00
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;
2005-08-21 03:52:55 -07:00
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>
2005-08-13 18:28:51 -07:00
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>
2005-08-13 18:28:50 -07:00
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>
2005-08-10 10:22:49 -07:00
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>
2005-08-05 00:51:07 -07:00