Re: [PATCH v6 2/3] revision: add peek functions for lookahead

>
> Kristofer Karlsson <krka@spotify.com> writes:
>
> > The solution is to skip peeking entirely and instead call
> > get_revision_internal() to populate a small lookahead buffer -
> > it only needs two slots.
> >
> >     struct git_graph {
> >         // ...
> >         struct commit *lookahead[2];
> >         int lookahead_nr;
> >     }
> >
> >     while (revs->graph->lookahead_nr < 2) {
> >         struct commit *next = get_revision_internal(revs);
> >         if (!next)
> >             break;
> >         graph_push_lookahead(revs->graph, next);
> >     }
> >
> > After prototyping this locally, the three test_expect_failure
> > cases in t4218 went away (though I had to do some minor tweaks
> > to ensure it become fully deterministic by ticking the commit
> > timestamps.
> >
> > One subtlety worth mentioning: get_revision_internal() sets
> > SHOWN on commits, so lookahead commits are marked SHOWN before
> > graph_update() processes them. This makes graph_is_interesting()
> > think they are already displayed. The fix is a small check in
> > graph_is_interesting() that recognizes commits in the lookahead
> > buffer as interesting regardless of their SHOWN flag.
> >
> >     for (i = 0; i < graph->lookahead_nr; i++)
> >         if (graph->lookahead[i] == commit)
> >             return 1;
> >     // other checks after this ...
> >
> > This approach ultimately removes the need for
> > revision_peek_next_commit() and revision_has_commits_after()
> > entirely - the graph code no longer needs to peek
> > at rev_info internals.
>
> Sorry I lost track, but I think the message I am responding to is
> one of the latest messages in the thread.  Whose court is the
> ball in right now?