git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* BUG: attempt to trim too many characters
@ 2017-09-05 21:39 Linus Torvalds
  2017-09-05 21:50 ` Jeff King
  0 siblings, 1 reply; 9+ messages in thread
From: Linus Torvalds @ 2017-09-05 21:39 UTC (permalink / raw)
  To: Junio C Hamano, Michael Haggerty; +Cc: Git Mailing List

I just got this with

   gitk --bisect

while doing some bisection on my current kernel.

It happens with "git rev-parse --bisect" too, but interestingly, "git
log --bisect" works fine.

I have not tried to figure out anything further, except that it was
introduced by commit b9c8e7f2f ("prefix_ref_iterator: don't trim too
much") and it happens with

   iter->iter0->refname = "refs/bisect/bad"
   iter->trim = 15

(where 15 is also the same as the length of that refname).

Not having time to chase this down any more, since I'm busy with the
merge window (and that annoying bisect)

              Linus

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: BUG: attempt to trim too many characters
  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
  0 siblings, 1 reply; 9+ messages in thread
From: Jeff King @ 2017-09-05 21:50 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Junio C Hamano, Michael Haggerty, Git Mailing List

On Tue, Sep 05, 2017 at 02:39:05PM -0700, Linus Torvalds wrote:

> I just got this with
> 
>    gitk --bisect
> 
> while doing some bisection on my current kernel.
> 
> It happens with "git rev-parse --bisect" too, but interestingly, "git
> log --bisect" works fine.
> 
> I have not tried to figure out anything further, except that it was
> introduced by commit b9c8e7f2f ("prefix_ref_iterator: don't trim too
> much") and it happens with
> 
>    iter->iter0->refname = "refs/bisect/bad"
>    iter->trim = 15
> 
> (where 15 is also the same as the length of that refname).
> 
> Not having time to chase this down any more, since I'm busy with the
> merge window (and that annoying bisect)

What version of git are you running? This should be fixed by 03df567fbf
(for_each_bisect_ref(): don't trim refnames, 2017-06-18) which is in
v2.14.

More discussion at

  https://public-inbox.org/git/cover.1497792827.git.mhagger@alum.mit.edu/

-Peff

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: BUG: attempt to trim too many characters
  2017-09-05 21:50 ` Jeff King
@ 2017-09-05 21:55   ` Linus Torvalds
  2017-09-05 22:03     ` Jeff King
  0 siblings, 1 reply; 9+ messages in thread
From: Linus Torvalds @ 2017-09-05 21:55 UTC (permalink / raw)
  To: Jeff King; +Cc: Junio C Hamano, Michael Haggerty, Git Mailing List

On Tue, Sep 5, 2017 at 2:50 PM, Jeff King <peff@peff.net> wrote:
>
> What version of git are you running? This should be fixed by 03df567fbf
> (for_each_bisect_ref(): don't trim refnames, 2017-06-18) which is in
> v2.14.

I'm way more recent than 2.14.

I'm at commit 238e487ea ("The fifth batch post 2.14")

              Linus

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: BUG: attempt to trim too many characters
  2017-09-05 21:55   ` Linus Torvalds
@ 2017-09-05 22:03     ` Jeff King
  2017-09-05 22:13       ` Linus Torvalds
  2017-09-13  4:29       ` BUG: attempt to trim too many characters Linus Torvalds
  0 siblings, 2 replies; 9+ messages in thread
From: Jeff King @ 2017-09-05 22:03 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Junio C Hamano, Michael Haggerty, Git Mailing List

On Tue, Sep 05, 2017 at 02:55:08PM -0700, Linus Torvalds wrote:

> On Tue, Sep 5, 2017 at 2:50 PM, Jeff King <peff@peff.net> wrote:
> >
> > What version of git are you running? This should be fixed by 03df567fbf
> > (for_each_bisect_ref(): don't trim refnames, 2017-06-18) which is in
> > v2.14.
> 
> I'm way more recent than 2.14.
> 
> I'm at commit 238e487ea ("The fifth batch post 2.14")

Ugh. Bitten again by the fact that rev-parse and revision.c implement
the same things in subtly different ways.

This probably fixes it:

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)) {

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: BUG: attempt to trim too many characters
  2017-09-05 22:03     ` Jeff King
@ 2017-09-05 22:13       ` Linus Torvalds
  2017-09-06 11:53         ` [PATCH] rev-parse: don't trim bisect refnames Jeff King
  2017-09-13  4:29       ` BUG: attempt to trim too many characters Linus Torvalds
  1 sibling, 1 reply; 9+ messages in thread
From: Linus Torvalds @ 2017-09-05 22:13 UTC (permalink / raw)
  To: Jeff King; +Cc: Junio C Hamano, Michael Haggerty, Git Mailing List

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

Yup. Thanks.

           Linus

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH] rev-parse: don't trim bisect refnames
  2017-09-05 22:13       ` Linus Torvalds
@ 2017-09-06 11:53         ` Jeff King
  2017-09-06 15:09           ` Michael Haggerty
  0 siblings, 1 reply; 9+ messages in thread
From: Jeff King @ 2017-09-06 11:53 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Junio C Hamano, Michael Haggerty, Git Mailing List

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


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH] rev-parse: don't trim bisect refnames
  2017-09-06 11:53         ` [PATCH] rev-parse: don't trim bisect refnames Jeff King
@ 2017-09-06 15:09           ` Michael Haggerty
  0 siblings, 0 replies; 9+ messages in thread
From: Michael Haggerty @ 2017-09-06 15:09 UTC (permalink / raw)
  To: Jeff King; +Cc: Linus Torvalds, Junio C Hamano, Git Mailing List

On Wed, Sep 6, 2017 at 1:53 PM, Jeff King <peff@peff.net> wrote:
> [...]
> 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).

It looks good to me.

Michael

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: BUG: attempt to trim too many characters
  2017-09-05 22:03     ` Jeff King
  2017-09-05 22:13       ` Linus Torvalds
@ 2017-09-13  4:29       ` Linus Torvalds
  2017-09-13 11:06         ` Jeff King
  1 sibling, 1 reply; 9+ messages in thread
From: Linus Torvalds @ 2017-09-13  4:29 UTC (permalink / raw)
  To: Jeff King; +Cc: Junio C Hamano, Michael Haggerty, Git Mailing List

Just reminding people that this issue would seem to still exist in
current master..

It's trivial to show:

   [torvalds@i7 git]$ git bisect start
   [torvalds@i7 git]$ git bisect bad master
   [torvalds@i7 git]$ git bisect good master~5
   Bisecting: 23 revisions left to test after this (roughly 5 steps)
   [f35a1d75b5ecefaef7b1a8ec55543c82883df82f] Merge branch
'rs/t3700-clean-leftover' into maint
   [torvalds@i7 git]$ git rev-parse --bisect
   fatal: BUG: attempt to trim too many characters

(Note: I use "git rev-parse --bisect" to show it as an error on the
command line, but normal people would obviously do "gitk --bisect"
that then does that "git rev-parse" internally and shows a UI error
box instead).

              Linus

On Tue, Sep 5, 2017 at 3:03 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Sep 05, 2017 at 02:55:08PM -0700, Linus Torvalds wrote:
>
>> On Tue, Sep 5, 2017 at 2:50 PM, Jeff King <peff@peff.net> wrote:
>> >
>> > What version of git are you running? This should be fixed by 03df567fbf
>> > (for_each_bisect_ref(): don't trim refnames, 2017-06-18) which is in
>> > v2.14.
>>
>> I'm way more recent than 2.14.
>>
>> I'm at commit 238e487ea ("The fifth batch post 2.14")
>
> Ugh. Bitten again by the fact that rev-parse and revision.c implement
> the same things in subtly different ways.
>
> This probably fixes it:
>
> 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)) {

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: BUG: attempt to trim too many characters
  2017-09-13  4:29       ` BUG: attempt to trim too many characters Linus Torvalds
@ 2017-09-13 11:06         ` Jeff King
  0 siblings, 0 replies; 9+ messages in thread
From: Jeff King @ 2017-09-13 11:06 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Junio C Hamano, Michael Haggerty, Git Mailing List

On Tue, Sep 12, 2017 at 09:29:49PM -0700, Linus Torvalds wrote:

> Just reminding people that this issue would seem to still exist in
> current master..

Yeah, the fix is in 1d0538e4860, but it's still working it's way up
through the integration branches.

-Peff

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2017-09-13 11:06 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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         ` [PATCH] rev-parse: don't trim bisect refnames Jeff King
2017-09-06 15:09           ` Michael Haggerty
2017-09-13  4:29       ` BUG: attempt to trim too many characters Linus Torvalds
2017-09-13 11:06         ` Jeff King

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).