Re: [jgit-dev] guru question about RevWalk - RevCommit buffer suddenly n

[Shawn Pearce <spearce@xxxxxxxxxxx>]

On Fri, Jun 1, 2012 at 4:45 AM, Markus Duft <markus.duft@xxxxxxxxxx> wrote:
> Hey
>
> I have written some code that does some (company specific) branch analysis based on commit messages and such. I re-use the RevWalk instance on a second call. Since i added a call to markUninteresting(), things started to go bad: if i see a commit in a later call again that was uninteresting in a previous one, it's internal buffer seems to be null...
>
> i think the relevant code is in the PendingGenerator, where it disposeBody()s the commits body if the commit is uninteresting. The RevWalk caches the commit, and won't parse it again, as it keeps it's parsed flag. Now every call to get*Message() for example will fail with a NPE, even though PARSED is there...
>
> is there a way (apart from throwing away the RevWalk, which works ;)) to keep the caches, and still use uninteresting commits? currently i manually call walk.parseBody(walked) on all commits that the walk returns, just in case (that works, but somehow it feels wrong...).

This is basically correct. We discard the body of an UNINTERESTING
commit to reduce memory load. The PARSED flag means we have the
structure of the commit loaded in order to have it participate in
traversals. It does not imply that the body buffer and the additional
metadata like author name are available. For that you need to make
sure parseBody is called.

The walker promises that results returned that are interesting should
have bodies. There may be a bug here that we don't do this when a
commit switches from UNINTERESTING. Thus far I have said that its up
to the application that is running a RevWalk more than once that may
have this state change happen worry about doing the parseBody call
itself, rather than having RevWalk always do the check internally
before returning a result, because it makes the common case of running
a RevWalk once faster.  :-)