Jeff King <p...@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-<. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
