| Re: [jgit-dev] RevWalk.next() 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. Thanks, Mingyu 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 >JGit? > >Cheers, >Tomek > >[1] >https://urldefense.proofpoint.com/v1/url?u=https://www.kernel.org/pub/soft >ware/scm/git/docs/git-log.html%23_commit_limiting&k=fDZpZZQMmYwf27OU23GmAQ >%3D%3D%0A&r=UKDOcu6qL3KsoZhpOohNBR1ucPNmWnbd3eEJ9hVUdMk%3D%0A&m=tUi%2BDsz% >2FN5PpGTUgQ8AVFro8Is2S7dLCEZhBP3MQYXo%3D%0A&s=22c53e4fde2bedd4e2850f62f284 >f9ada68a0f6d3d5b9c5585d3efb4a6e58d75 > >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 = 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 >> >> >> _______________________________________________ >> jgit-dev mailing list >> jgit-dev@xxxxxxxxxxx >> >>https://urldefense.proofpoint.com/v1/url?u=https://dev.eclipse.org/mailma >>n/listinfo/jgit-dev&k=fDZpZZQMmYwf27OU23GmAQ%3D%3D%0A&r=UKDOcu6qL3KsoZhpO >>ohNBR1ucPNmWnbd3eEJ9hVUdMk%3D%0A&m=tUi%2BDsz%2FN5PpGTUgQ8AVFro8Is2S7dLCEZ >>hBP3MQYXo%3D%0A&s=abb31d8915ba4ee2618c81015e602f01562f24d8e40ed9b522ce79a >>33eff3991 >>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature