From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 04 Dec 2014 22:14:50 GMT
Subject: Re: Bug in reflog of length 0x2BFF
Message-ID: <xmqq388vrrj9.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20141204215805.GD19953@peff.net>

Jeff King <peff@peff.net> writes:

> I think the bug is in the reverse-reflog reader in
> for_each_reflog_ent_reverse. It reads BUFSIZ chunks of the file in
> reverse order, and then parses them individually. If the trailing
> newline for a line falls directly on the block boundary, we may not have
> it in our current block, and pass the line to show_one_reflog_ent
> without a trailing newline.

Ahh, thanks for helping spot it.  A code that uses BUFSIZ explains
why a single reproduction recipe is platform dependent.

> So this is a long-standing bug in for_each_reflog_ent_reverse. It just
> showed up recently because we started using that function for
> read_ref_at_ent.
> ...
> The above is a workaround. I think the right solution is probably to
> teach for_each_reflog_ent_reverse to makes sure the trailing newline is
> included (either by tweaking the reverse code, or conditionally adding
> it to the parsed buffer).

Sounds correct.  Unfortunately I no longer remember how I decided to
deal with a line that spans the block boundary in that piece of code
X-<.