logmsg_reencode: lazily load missing commit buffers
authorJeff King <peff@peff.net>
Sat, 26 Jan 2013 09:44:28 +0000 (04:44 -0500)
committerJunio C Hamano <gitster@pobox.com>
Sat, 26 Jan 2013 21:28:22 +0000 (13:28 -0800)
commitbe5c9fb9049ed470e7005f159bb923a5f4de1309
tree41dbf31b64bb82400bad0c20ec3cee0f1e3d9c90
parentdd0d388c44c28ebc021a24eeddc60287d4ea249c
logmsg_reencode: lazily load missing commit buffers

Usually a commit that makes it to logmsg_reencode will have
been parsed, and the commit->buffer struct member will be
valid. However, some code paths will free commit buffers
after having used them (for example, the log traversal
machinery will do so to keep memory usage down).

Most of the time this is fine; log should only show a commit
once, and then exits. However, there are some code paths
where this does not work. At least two are known:

  1. A commit may be shown as part of a regular ref, and
     then it may be shown again as part of a submodule diff
     (e.g., if a repo contains refs to both the superproject
     and subproject).

  2. A notes-cache commit may be shown during "log --all",
     and then later used to access a textconv cache during a
     diff.

Lazily loading in logmsg_reencode does not necessarily catch
all such cases, but it should catch most of them. Users of
the commit buffer tend to be either parsing for structure
(in which they will call parse_commit, and either we will
already have parsed, or we will load commit->buffer lazily
there), or outputting (either to the user, or fetching a
part of the commit message via format_commit_message). In
the latter case, we should always be using logmsg_reencode
anyway (and typically we do so via the pretty-print
machinery).

If there are any cases that this misses, we can fix them up
to use logmsg_reencode (or handle them on a case-by-case
basis if that is inappropriate).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/blame.c
pretty.c
t/t4042-diff-textconv-caching.sh