git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Junio C Hamano <gitster@pobox.com>,
	Michael Haggerty <mhagger@alum.mit.edu>,
	Git Mailing List <git@vger.kernel.org>
Subject: [PATCH] rev-parse: don't trim bisect refnames
Date: Wed, 6 Sep 2017 07:53:10 -0400	[thread overview]
Message-ID: <20170906115310.kxgjrnmrehm5m32q@sigill.intra.peff.net> (raw)
In-Reply-To: <CA+55aFw==7bqv0dH=cQruXbGjMw-WNrRMreMsYy_4NcrbiWSEA@mail.gmail.com>

On Tue, Sep 05, 2017 at 03:13:41PM -0700, Linus Torvalds wrote:

> On Tue, Sep 5, 2017 at 3:03 PM, Jeff King <peff@peff.net> wrote:
> >
> > This probably fixes it:
> 
> Yup. Thanks.

Thanks for confirming. Here it is with a commit message and test.

-- >8 --
Subject: [PATCH] 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>
---
 builtin/rev-parse.c        |  4 ++--
 t/t6002-rev-list-bisect.sh | 18 ++++++++++++++++--
 2 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index 2bd28d3c08..9f24004c0a 100644
--- a/builtin/rev-parse.c
+++ b/builtin/rev-parse.c
@@ -757,8 +757,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)) {
diff --git a/t/t6002-rev-list-bisect.sh b/t/t6002-rev-list-bisect.sh
index 534903bbd2..a661408038 100755
--- a/t/t6002-rev-list-bisect.sh
+++ b/t/t6002-rev-list-bisect.sh
@@ -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
-- 
2.14.1.757.g8fad538cea


  reply	other threads:[~2017-09-06 11:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-05 21:39 BUG: attempt to trim too many characters Linus Torvalds
2017-09-05 21:50 ` Jeff King
2017-09-05 21:55   ` Linus Torvalds
2017-09-05 22:03     ` Jeff King
2017-09-05 22:13       ` Linus Torvalds
2017-09-06 11:53         ` Jeff King [this message]
2017-09-06 15:09           ` [PATCH] rev-parse: don't trim bisect refnames Michael Haggerty
2017-09-13  4:29       ` BUG: attempt to trim too many characters Linus Torvalds
2017-09-13 11:06         ` 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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20170906115310.kxgjrnmrehm5m32q@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mhagger@alum.mit.edu \
    --cc=torvalds@linux-foundation.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).