StringIndexOutOfBoundsException & missing results navigation buttons

[gitblit]

Originally reported on Google Code with ID 105

What steps will reproduce the problem?
1.search
2.*term1* AND term2.*
3.doesn't happen every time though...

What is the expected output? What do you see instead?
Expecting to see results w/ next/previous/page# buttons.
No next button, but first x out of N results display (can't see the rest of the results)

What version of the product are you using? On what operating system?
v0.9.3
RHEL6

Please provide any additional information below.
(see attached trace)

Reported by benrose3d on 2012-07-10 22:43:24

---

- _Attachment: [gitBlitexception1.txt](https://storage.googleapis.com/google-code-attachments/gitblit/issue-105/comment-0/gitBlitexception1.txt)_

[gitblit]

I should point out that it happens every time once you find a case it does happen. 
I meant that it doesn't happen with just any search criteria.

Reported by benrose3d on 2012-07-10 22:44:44

[gitblit]

Reported by James.Moger on 2012-07-11 00:43:34

• Status changed: Accepted
• Labels added: Milestone-1.0.0

[gitblit]

This is a tricky one.  I can't trigger the scenario.  Is the repository a public one
so I can use your query?

Reported by James.Moger on 2012-07-11 00:54:36

[gitblit]

Unfortunately that is not the case.  I will try to dupe it on the openshift demo.

Reported by benrose3d on 2012-07-11 01:03:13

[gitblit]

Ok.  I understand the issue.

Gitblit takes the fragments Lucene identifies as "best" and tries to determine the
position of each fragment within the original source file.  Gitblit does this to include
line numbers in the generated output, which can be helpful in your searching.

The assumption was that the "best" fragments were returned in logical order relative
to the file.  Unfortunately, they are returned in a scored order which may or may not
be commensurate with their logical order.

The line-number-hunting algorithm tracks position so it does not have to re-process
the entire file for each fragment.  This is where your exception comes from.  Gitblit
is trying to find fragment2 after fragment1 (fragment1 = best fragment) because it
assumes the fragments are in logical order.  But in your case fragment1 is located
after fragment2.  Gitblit can't find fragment2 at all because it is only looking at
the portion of the file after fragment1.  This screws up everything.  :)

Having a test case to ensure I have fixed it would be useful, if you can arrange it.

Reported by James.Moger on 2012-07-11 01:34:04

[gitblit]

Reported by James.Moger on 2012-07-11 21:36:41

• Status changed: Queued

[gitblit]

Resolved in v1.0.0.

Reported by James.Moger on 2012-07-14 04:44:17

• Status changed: Done