Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jgit-dev] RevWalk.next() visits all commits on the first call when tree filter is not ALL

I was using LogCommand to get the commit history for a particular file. Here's a code snippet.

Iterable<RevCommit> iterable = git.log().add(startCommit).addPath(path).call(); // this is actually a RevWalk
Iterator<RevCommit> iterator = iterable.iterator();
While (iterator.hasNext()) {
RevCommit next = iterator.next();
// do something
// break if certain condition is met
}

I noticed that the second line that initializes the iterator takes a long time and the running time grows linearly with the number of commits. After some more investigation, I noticed the entire log was computed at the second line, rather than being computed on demand when I call next(). The second line calls RevWalk.next(), which then calls StartGenerator.next(), and StartGenerator.next() creates FIFORevQueue if the tree filter is not ALL. (It's not ALL in my case because I added a path filter.) At construction, FIFORevQueue keeps calling Generator.next() until it returns null, which I believe visits all commits in the repository from the start point to the very initial commit.

Basically, I'd like to be able to run the code snippet above and to pay the cost only for what's actually needed to fetch just the next commit because I will often break the loop in the middle after a couple of commits. Is there a way to avoid computing the entire log at the beginning and to do computation on-demans as I iterate through the commits? Is there any plan to fix this in the short term? I know I can simply iterate through the commits with a ALL tree filter and perform path filtering myself, but I'm wondering if there is a way to do this in a more native way in jgit.

Thanks,
Mingyu

Attachment: smime.p7s
Description: S/MIME cryptographic signature


Back to the top