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.

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

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

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.

Resolved in v1.0.0.