Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] visits all commits on the first call when tree filter is not ALL

I was able to repro this in 3.0.

I haven't tried setMaxCount, but that may do the job. I decided to just
get the log without the path filtering and do a manual path filtering. All
I wanted to do was an on-demand loading of the commits and doing manual
path filtering works well at least for me.

My point was just that jgit log command with a path filter doesn't stream
the result (the API implicitly suggests on-demand streaming) and does
compute the entire commit history by the time iterator is created. I
wouldn't say this is a very high priority, because there are a couple of
work-around including manual path filtering.


On 7/1/13 1:22 PM, "Tomasz Zarna" <tzarna@xxxxxxxxx> wrote:

>Hi Mingyu,
>> I will often break the loop in the middle after a couple of commits
>Not sure which JGit version are you using, but in case it's not the
>latest one: is the condition you meet something that can be set using
>LogCommand#setMaxCount, #setSkip or alike? If not, is it something
>that can be achieved in native git [1], but the API is missing in
>On Thu, Jun 27, 2013 at 12:48 AM, Mingyu Kim <mkim@xxxxxxxxxxxx> wrote:
>> 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 =;
>> // do something
>> // break if certain condition is met
>> }
>> I noticed that the second line that initializes the iterator takes a
>> time and the running time grows linearly with the number of commits.
>> some more investigation, I noticed the entire log was computed at the
>> line, rather than being computed on demand when I call next(). The
>> line calls, which then calls, and
>> creates FIFORevQueue if the tree filter is not
>> (It's not ALL in my case because I added a path filter.) At
>> FIFORevQueue keeps calling 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
>> 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
>> 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
>> with a ALL tree filter and perform path filtering myself, but I'm
>> if there is a way to do this in a more native way in jgit.
>> Thanks,
>> Mingyu
>> _______________________________________________
>> jgit-dev mailing list
>> jgit-dev@xxxxxxxxxxx

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

Back to the top