I've done that and I think it's acceptable for most use cases that one has to decide whether to use plain RevWalk or MergeBaseWalk.

However now resulting code looks like it could be turned into a Generator as well: we could introduce RevWalk.stopOnMergeBase which would create a MergeBaseGenerator that will be put between PendingGenerator and sorting-dependent Generators in the Generator pipeline.

There will be two implementations of MergeBaseGenerator: the one which is already existing, working for a few start commits only and the new BitSet-based implementation. Depending on the implementation usual RevCommit or extended RevCommitWithBitSet will be created by RevWalk.

This approach will require that both MergeBaseGenerator implementations can be chained like the other generators. Why is this currently not possible for the already existing implementation: "Computing for merge bases is a special case and does not use the bulk of the generator pipeline."?

Another issue: RevWalk.stopOnMergeBase must definitely be called before the Walk is started. What would happen, if there have been normal RevCommits created by a previous run, then reset() is called, stopOnMergeBase is set, and the RevWalk is started again and requires now RevCommitWithBitSet?