git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Subject: [PATCH v4 12/18] sha1_name.c: get_describe_name() by definition groks only commits
Date: Mon,  2 Jul 2012 15:34:03 -0700	[thread overview]
Message-ID: <1341268449-27801-13-git-send-email-gitster@pobox.com> (raw)
In-Reply-To: <1341268449-27801-1-git-send-email-gitster@pobox.com>

Teach get_describe_name() to pass the disambiguation hint down the
callchain to get_short_sha1().

Also add tests to show various syntactic elements that we could take
advantage of the object type information to help disambiguration of
abbreviated object names.  Many of them are marked as broken, and
some of them will be fixed in later patches in this series.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 sha1_name.c                         |   3 +-
 t/t1512-rev-parse-disambiguation.sh | 208 ++++++++++++++++++++++++++++++++++++
 2 files changed, 210 insertions(+), 1 deletion(-)
 create mode 100755 t/t1512-rev-parse-disambiguation.sh

diff --git a/sha1_name.c b/sha1_name.c
index be15d94..9af84b1 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -603,6 +603,7 @@ static int peel_onion(const char *name, int len, unsigned char *sha1)
 static int get_describe_name(const char *name, int len, unsigned char *sha1)
 {
 	const char *cp;
+	unsigned flags = GET_SHA1_QUIETLY | GET_SHA1_COMMIT;
 
 	for (cp = name + len - 1; name + 2 <= cp; cp--) {
 		char ch = *cp;
@@ -613,7 +614,7 @@ static int get_describe_name(const char *name, int len, unsigned char *sha1)
 			if (ch == 'g' && cp[-1] == '-') {
 				cp++;
 				len -= cp - name;
-				return get_short_sha1(cp, len, sha1, GET_SHA1_QUIETLY);
+				return get_short_sha1(cp, len, sha1, flags);
 			}
 		}
 	}
diff --git a/t/t1512-rev-parse-disambiguation.sh b/t/t1512-rev-parse-disambiguation.sh
new file mode 100755
index 0000000..42701ad
--- /dev/null
+++ b/t/t1512-rev-parse-disambiguation.sh
@@ -0,0 +1,208 @@
+#!/bin/sh
+
+test_description='object name disambiguation
+
+Create blobs, trees, commits and a tag that all share the same
+prefix, and make sure "git rev-parse" can take advantage of
+type information to disambiguate short object names that are
+not necessarily unique.
+
+The final history used in the test has five commits, with the bottom
+one tagged as v1.0.0.  They all have one regular file each.
+
+  +-------------------------------------------+
+  |                                           |
+  |           .-------cs60sb5----- d59np2z    |
+  |          /                   /            |
+  |  d8znjge0 ---a2dit76---b4crl15            |
+  |                                           |
+  +-------------------------------------------+
+
+'
+
+. ./test-lib.sh
+
+test_expect_success 'blob and tree' '
+	(
+		for i in 0 1 2 3 4 5 6 7 8 9
+		do
+			echo $i
+		done
+		echo
+		echo cbpkuqa
+	) >bz01t33 &&
+
+	# create one blob 1102198254
+	git add bz01t33 &&
+
+	# create one tree 1102198206
+	git write-tree
+'
+
+test_expect_failure 'disambiguate tree-ish' '
+	# feed tree-ish in an unambiguous way
+	git rev-parse --verify 1102198206:bz01t33 &&
+
+	# ambiguous at the object name level, but there is only one
+	# such tree-ish (the other is a blob)
+	git rev-parse --verify 11021982:bz01t33
+'
+
+test_expect_success 'first commit' '
+	# create one commit 1102198268
+	test_tick &&
+	git commit -m d8znjge0
+'
+
+test_expect_failure 'disambiguate commit-ish' '
+	# feed commit-ish in an unambiguous way
+	git rev-parse --verify 1102198268^{commit} &&
+
+	# ambiguous at the object name level, but there is only one
+	# such commit (the others are tree and blob)
+	git rev-parse --verify 11021982^{commit} &&
+
+	# likewise
+	git rev-parse --verify 11021982^0
+'
+
+test_expect_failure 'name1..name2 takes only commit-ishes on both ends' '
+	git log 11021982..11021982 &&
+	git log ..11021982 &&
+	git log 11021982.. &&
+	git log 11021982...11021982 &&
+	git log ...11021982 &&
+	git log 11021982...
+'
+
+test_expect_failure 'git log takes only commit-ish' '
+	git log 11021982
+'
+
+test_expect_success 'first tag' '
+	# create one tag 1102198256
+	git tag -a -m d3g97ek v1.0.0
+'
+
+test_expect_failure 'two semi-ambiguous commit-ish' '
+	# Once the parser becomes ultra-smart, it could notice that
+	# 110282 before ^{commit} name many different objects, but
+	# that only two (HEAD and v1.0.0 tag) can be peeled to commit,
+	# and that peeling them down to commit yield the same commit
+	# without ambiguity.
+	git rev-parse --verify 110282^{commit} &&
+
+	# likewise
+	git log 11021982..11021982 &&
+	git log ..11021982 &&
+	git log 11021982.. &&
+	git log 11021982...11021982 &&
+	git log ...11021982 &&
+	git log 11021982...
+'
+
+test_expect_failure 'three semi-ambiguous tree-ish' '
+	# Likewise for tree-ish.  HEAD, v1.0.0 and HEAD^{tree} share
+	# the prefix but peeling them to tree yields the same thing
+	git rev-parse --verify 110282^{tree}
+'
+
+test_expect_success 'parse describe name' '
+	# feed an unambiguous describe name
+	git rev-parse --verify v1.0.0-0-g1102198268 &&
+
+	# ambiguous at the object name level, but there is only one
+	# such commit (others are blob, tree and tag)
+	git rev-parse --verify v1.0.0-0-g11021982
+'
+
+test_expect_success 'more history' '
+	# commit 110219822
+	git mv bz01t33 b90au8x &&
+	echo bdc8xi8 >>b90au8x &&
+	git add b90au8x &&
+
+	test_tick &&
+	git commit -m a2dit76 &&
+
+	# commit 110219828
+	git mv b90au8x djintr2 &&
+	echo a2a49zt >>djintr2 &&
+	git add djintr2 &&
+
+	test_tick &&
+	git commit -m b4crl15 &&
+
+	# commit 11021982d
+	git checkout v1.0.0^0 &&
+	git mv bz01t33 ddp2qt1 &&
+
+	for i in bdc8xi8 a2a49zt c0l9aeu
+	do
+		echo $i
+	done >>ddp2qt1 &&
+	git add ddp2qt1 &&
+
+	test_tick &&
+	git commit -m cs60sb5 &&
+	side=$(git rev-parse HEAD) &&
+
+	# commit 11021982a
+	git checkout master &&
+
+	# If you use recursive, merge will fail and you will need to
+	# clean up bz01t33 as well.  If you use resolve, merge will
+	# succeed.
+	test_might_fail git merge --no-commit -s resolve $side &&
+	git rm -f ddp2qt1 djintr2 &&
+	test_might_fail git rm -f bz01t33 &&
+	(
+		git cat-file blob $side:ddp2qt1
+		echo d4o8f4f
+	) >c3q9963 &&
+	git add c3q9963 &&
+
+	test_tick &&
+	git commit -m d59np2z
+
+'
+
+test_expect_failure 'parse describe name taking advantage of generation' '
+	# ambiguous at the object name level, but there is only one
+	# such commit at generation 0
+	git rev-parse --verify v1.0.0-0-g11021982 &&
+
+	# likewise for generation 2 and 4
+	git rev-parse --verify v1.0.0-2-g11021982 &&
+	git rev-parse --verify v1.0.0-4-g11021982
+'
+
+# Note: because rev-parse does not even try to disambiguate based on
+# the generation number, this test currently succeeds for a wrong
+# reason.  When it learns to use the generation number, the previous
+# test should succeed, and also this test should fail because the
+# describe name used in the test with generation number can name two
+# commits.  Make sure that such a future enhancement does not randomly
+# pick one.
+test_expect_success 'parse describe name not ignoring ambiguity' '
+	# ambiguous at the object name level, and there are two such
+	# commits at generation 1
+	test_must_fail git rev-parse --verify v1.0.0-1-g11021982
+'
+
+test_expect_success 'ambiguous commit-ish' '
+	# Now there are many commits that begin with the
+	# common prefix, none of these should pick one at
+	# random.  They all should result in ambiguity errors.
+	test_must_fail git rev-parse --verify 110282^{commit} &&
+
+	# likewise
+	test_must_fail git log 11021982..11021982 &&
+	test_must_fail git log ..11021982 &&
+	test_must_fail git log 11021982.. &&
+	test_must_fail git log 11021982...11021982 &&
+	test_must_fail git log ...11021982 &&
+	test_must_fail git log 11021982...
+'
+
+test_done
-- 
1.7.11.1.212.g52fe12e

  parent reply	other threads:[~2012-07-02 22:35 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-02 22:33 [PATCH v4 00/18] Extending the shelf-life of "git describe" output Junio C Hamano
2012-07-02 22:33 ` [PATCH v4 01/18] sha1_name.c: indentation fix Junio C Hamano
2012-07-02 22:33 ` [PATCH v4 02/18] sha1_name.c: hide get_sha1_with_context_1() ugliness Junio C Hamano
2012-07-02 22:33 ` [PATCH v4 03/18] sha1_name.c: get rid of ugly get_sha1_with_mode_1() Junio C Hamano
2012-07-03  8:01   ` Matthieu Moy
2012-07-03 17:19     ` Junio C Hamano
2012-07-04  7:12       ` Matthieu Moy
2012-07-02 22:33 ` [PATCH v4 04/18] sha1_name.c: get rid of get_sha1_with_mode() Junio C Hamano
2012-07-02 22:33 ` [PATCH v4 05/18] sha1_name.c: clarify what "fake" is for in find_short_object_filename() Junio C Hamano
2012-07-02 22:33 ` [PATCH v4 06/18] sha1_name.c: rename "now" to "current" Junio C Hamano
2012-07-02 22:33 ` [PATCH v4 07/18] sha1_name.c: refactor find_short_packed_object() Junio C Hamano
2012-07-02 22:33 ` [PATCH v4 08/18] sha1_name.c: correct misnamed "canonical" and "res" Junio C Hamano
2012-07-02 22:34 ` [PATCH v4 09/18] sha1_name.c: restructure disambiguation of short names Junio C Hamano
2012-07-02 22:34 ` [PATCH v4 10/18] sha1_name.c: allow get_short_sha1() to take other flags Junio C Hamano
2012-07-02 22:34 ` [PATCH v4 11/18] sha1_name.c: teach get_short_sha1() a commit-only option Junio C Hamano
2012-07-02 22:34 ` Junio C Hamano [this message]
2012-07-02 22:34 ` [PATCH v4 13/18] sha1_name.c: get_sha1_1() takes lookup flags Junio C Hamano
2012-07-02 22:34 ` [PATCH v4 14/18] sha1_name.c: many short names can only be committish Junio C Hamano
2012-07-02 23:01   ` Junio C Hamano
2012-07-02 22:34 ` [PATCH v4 15/18] sha1_name.c: teach lookup context to get_sha1_with_context() Junio C Hamano
2012-07-02 22:34 ` [PATCH v4 16/18] sha1_name.c: introduce get_sha1_committish() Junio C Hamano
2012-07-02 22:34 ` [PATCH v4 17/18] revision.c: allow handle_revision_arg() to take other flags Junio C Hamano
2012-07-02 22:34 ` [PATCH v4 18/18] revision.c: the "log" family, except for "show", takes committish Junio C Hamano
2012-07-03  7:19 ` [PATCH v4 00/18] Extending the shelf-life of "git describe" output Jeff King
2012-07-03 17:19   ` Junio C Hamano
2012-07-03 18:20   ` Junio C Hamano
2012-07-03 18:38     ` Jeff King
2012-07-03 18:41       ` Junio C Hamano
2012-07-03 19:34         ` Jeff King
2012-07-03 20:21           ` Junio C Hamano
2012-07-03 20:24             ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1341268449-27801-13-git-send-email-gitster@pobox.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).