rev-parse: don't trim bisect refnames

Using for_each_ref_in() with a full refname has always been
a questionable practice, but it became an error with
b9c8e7f2fb (prefix_ref_iterator: don't trim too much,
2017-05-22), making "git rev-parse --bisect" pretty reliably
show a BUG.

Commit 03df567fbf (for_each_bisect_ref(): don't trim
refnames, 2017-06-18) fixed this case for revision.c, but
rev-parse handles this option on its own. We can use the
same solution here (and piggy-back on its test).

Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Jeff King 2017-09-06 07:53:10 -04:00 committed by Junio C Hamano
parent 03df567fbf
commit 1d0538e486
2 changed files with 18 additions and 4 deletions

View File

@ -756,8 +756,8 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
continue;
}
if (!strcmp(arg, "--bisect")) {
for_each_ref_in("refs/bisect/bad", show_reference, NULL);
for_each_ref_in("refs/bisect/good", anti_reference, NULL);
for_each_fullref_in("refs/bisect/bad", show_reference, NULL, 0);
for_each_fullref_in("refs/bisect/good", anti_reference, NULL, 0);
continue;
}
if (opt_with_value(arg, "--branches", &arg)) {

View File

@ -236,17 +236,31 @@ test_sequence "--bisect"
#
#
test_expect_success '--bisect can default to good/bad refs' '
test_expect_success 'set up fake --bisect refs' '
git update-ref refs/bisect/bad c3 &&
good=$(git rev-parse b1) &&
git update-ref refs/bisect/good-$good $good &&
good=$(git rev-parse c1) &&
git update-ref refs/bisect/good-$good $good &&
git update-ref refs/bisect/good-$good $good
'
test_expect_success 'rev-list --bisect can default to good/bad refs' '
# the only thing between c3 and c1 is c2
git rev-parse c2 >expect &&
git rev-list --bisect >actual &&
test_cmp expect actual
'
test_expect_success 'rev-parse --bisect can default to good/bad refs' '
git rev-parse c3 ^b1 ^c1 >expect &&
git rev-parse --bisect >actual &&
# output order depends on the refnames, which in turn depends on
# the exact sha1s. We just want to make sure we have the same set
# of lines in any order.
sort <expect >expect.sorted &&
sort <actual >actual.sorted &&
test_cmp expect.sorted actual.sorted
'
test_done