From: Junio C Hamano <hidden> Date: 2016-06-15 22:46:33
Sverre Rabbelier [off-list ref] writes:
On Sat, Apr 4, 2009 at 22:59, Christian Couder [off-list ref] wrote:
quoted
+ if (lo <= mi && mi < hi)
+ break;
+ die("oops");
That's going to be an official git error message? Why not make it "The
It's not "going to be", but "has been so for the last two years since
5d23e13".
It is an assert, and I think Peff's die("BUG: ...") would be a good idea.
I think Junio is trying to learn base64 :)!
This is what `base64 -d` gives:
Sverre Rabbelier [off-list ref] writes:
On Sat, Apr 4, 2009 at 22:59, Christian Couder [off-list ref] wrote:
quoted
+ if (lo <= mi && mi < hi)
+ break;
+ die("oops");
That's going to be an official git error message? Why not make it "The
It's not "going to be", but "has been so for the last two years since
5d23e13".
It is an assert, and I think Peff's die("BUG: ...") would be a good idea.
From: Jeff King <hidden> Date: 2016-06-15 22:46:33
On Sun, Apr 05, 2009 at 09:06:56PM +0200, Sverre Rabbelier wrote:
quoted
It is an assert, and I think Peff's die("BUG: ...") would be a good idea.
As long as the <something that makes sense to the user> does indeed
make sense, right :).
I think:
die("BUG: assertion failed in binary search")
would be sufficient to tell the user what is going on, and let them
inform the list what happened.
However, if this "oops" has been there for 2 years and nobody has seen
it, it's entirely possible that somebody actually got the binary search
code right in the first place. ;)
-Peff
Heya,
On Sun, Apr 5, 2009 at 21:59, Jeff King [off-list ref] wrote:
die("BUG: assertion failed in binary search")
Given that we now only have one binary search (which should be re-used
everywhere), I think it's fair enough to describe it like that.
However, if this "oops" has been there for 2 years and nobody has seen
it, it's entirely possible that somebody actually got the binary search
code right in the first place. ;)
Hehe, never underestimate the difficulty of writing a proper binary
search! :P But I do agree two years of 'testing' is more than more
binary searches get before being 'released' ;).
--
Cheers,
Sverre Rabbelier
From: Jeff King <hidden> Date: 2016-06-15 22:46:33
On Sun, Apr 05, 2009 at 08:31:06PM +0100, Reece Dunn wrote:
This is what `base64 -d` gives:
[...]
It's not "going to be", but "has been so for the last two years since
5d23e13".
It is an assert, and I think Peff's die("BUG: ...") would be a good idea.
Interestingly, I get a bunch of unprintable crap at the end. The culprit
seems to be that vger stupidly adds:
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
to the bottom, regardless of transfer-encoding. At best, this is
pointless and invisible, as the reader will just show the base64
content. But some decoders (like mutt) actually treat non-base64
characters not as "end of base64" but as "ignore and keep looking for
more base64". So this decodes into a bunch of random characters. And to
make it even more fun, it only happens if the message is a certain
length; otherwise, it needs "=" fill characters at the end, which
unambiguously signal the end.
"openssl base64 -d" stops decoding at the cruft. But I think what mutt
is doing is right. According to RFC 2045:
The encoded output stream must be represented in lines of no more
than 76 characters each. All line breaks or other characters not
found in Table 1 must be ignored by decoding software. In base64
data, characters other than those in Table 1, line breaks, and
other white space probably indicate a transmission error, about
which a warning message or even a message rejection might be
appropriate under some circumstances.
I don't know if it is worth trying to get vger to be smarter. According
to this, they consider base64 text parts not worth handling:
http://lkml.indiana.edu/hypermail/linux/kernel/0304.0/0901.html
So maybe it is worth trying to get Junio not to send base64 mail. ;)
-Peff
Junio's _original_ message was fine. The problem is that vger
(majordomo) appends the mailing list footer which technically corrupts
the message. Respectable MUA's can deal with the corruption, but
gmail's web-interface just shows the raw base64 (previously it used to
just show an empty message). I've filed a bug against gmail, but who
knows.
The other options are:
- fix majordomo on vger
- replace majordomo on vger with a decent MLM
- disable the mailing list footer
- deal with it if you're a gmail user
j.