Because these constructs can be used to parse user input to be
passed to rev-list --objects, e.g.
range=$(git rev-parse v1.0..v2.0) &&
git rev-list --objects $range | git pack-objects --stdin
the endpoints (v1.0 and v2.0 in the example) are shown without
peeling them to underlying commits, even when they are annotated
tags. Make sure it stays that way.
While at it, ensure "rev-parse A...B" also keeps the endpoints A and
B unpeeled, even though the negative side (i.e. the merge-base
between A and B) has to become a commit.
Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
---
t/t1506-rev-parse-diagnosis.sh | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/t/t1506-rev-parse-diagnosis.sh b/t/t1506-rev-parse-diagnosis.sh
index dbf690b9c1..3e657e693b 100755
--- a/t/t1506-rev-parse-diagnosis.sh
+++ b/t/t1506-rev-parse-diagnosis.sh
@@ -190,6 +190,24 @@ test_expect_success 'dotdot is not an empty set' '
test_cmp expect actual
'
+test_expect_success 'dotdot does not peel endpoints' '
+ git tag -a -m "annote" annotated HEAD &&
+ A=$(git rev-parse annotated) &&
+ H=$(git rev-parse annotated^0) &&
+ {
+ echo $A && echo ^$A
+ } >expect-with-two-dots &&
+ {
+ echo $A && echo $A && echo ^$H
+ } >expect-with-merge-base &&
+
+ git rev-parse annotated..annotated >actual-with-two-dots &&
+ test_cmp expect-with-two-dots actual-with-two-dots &&
+
+ git rev-parse annotated...annotated >actual-with-merge-base &&
+ test_cmp expect-with-merge-base actual-with-merge-base
+'
+
test_expect_success 'arg before dashdash must be a revision (missing)' '
test_must_fail git rev-parse foobar -- 2>stderr &&
test_i18ngrep "bad revision" stderr
--
2.28.0-718-gd8d5e3da39
