Kristofer Karlsson [off-list ref] 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?

Thanks.