Do we *really* want to lock ourselves into the List concept as a result type here?  I suspect most users of this really just need an Iterable<RevCommit> so they can easily access it from a for loop iteration.  RevWalk already implements that.

If we do implement List here... we probably should try to be smart about it and make the list lazy to construct itself.  See RevCommitList for what I mean about that.  It probably doesn't fully implement the List API, and so has corner cases we would need to finish out.  But the general idea would be, don't materialize the entire result unless the caller forces us to with size(), or a get(int) call for the last element in the List.  Otherwise, materialize out only as far as they have asked for.

Sure, certain sorting types require us to materialize the whole thing first anyway.  But not all do.  And not all applications need us to materialize the entire thing in order to process the results.  Its why RevWalk uses Iterable as its main public interface.