Repo indexer not searching some method names #2736

New Issue

GiteaMirror · 2025-11-02T04:46:10-06:00

GiteaMirror commented

2025-11-02 04:46:10 -06:00

Originally created by @mcdamo on GitHub (Jan 10, 2019).

Gitea version (or commit ref): 1.6.3
Git version:
Operating system: FreeBSD
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant (indexer not enabled)
Log gist:

Description

I have code like $e->getMessage() but the indexer cannot search 'getMessage'.
To find this code I must search '*Message', but obviously that example brings up many unwanted results.

Code like $this->method() can be searched with 'method' so perhaps the indexer is splitting the camelcase words.

Originally created by @mcdamo on GitHub (Jan 10, 2019).  - Gitea version (or commit ref): 1.6.3 - Git version: - Operating system: FreeBSD - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant (indexer not enabled) - Log gist: ## Description I have code like `$e->getMessage()` but the indexer cannot search 'getMessage'. To find this code I must search '*Message', but obviously that example brings up many unwanted results. Code like `$this->method()` can be searched with 'method' so perhaps the indexer is splitting the camelcase words.

GiteaMirror added the issue/confirmed type/enhancement labels 2025-11-02 04:46:10 -06:00

GiteaMirror closed this issue

2025-11-02 04:46:10 -06:00

GiteaMirror commented

2025-11-02 04:46:11 -06:00

@stale[bot] commented on GitHub (Mar 12, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Mar 12, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 04:46:11 -06:00

@mcdamo commented on GitHub (Mar 12, 2019):

Possibly related #5277 (cannot search snake_case)

@mcdamo commented on GitHub (Mar 12, 2019): Possibly related #5277 (cannot search snake_case)

GiteaMirror commented

2025-11-02 04:46:11 -06:00

@guillep2k commented on GitHub (Aug 1, 2019):

Same here. For instance, I search for "main" and I get quite a few hits, but none of them is a main() function which I'm certain exists. It's not only a camel case problem, apparently. Also, it's not necessarily an index problem, but perhaps a retrieval problem?

But:

One might think: it's indexing Mon and Console separately, but with other words it works half-fine:

Here the .h definition is correctly found, but the corresponding .c implementation is not.

@guillep2k commented on GitHub (Aug 1, 2019): Same here. For instance, I search for "main" and I get quite a few hits, but none of them is a main() function which I'm certain exists. It's not only a camel case problem, apparently. Also, it's not necessarily an index problem, but perhaps a retrieval problem? ![image](https://user-images.githubusercontent.com/18600385/62300763-beea0500-b44d-11e9-82fe-d2d51b829273.png) ![image](https://user-images.githubusercontent.com/18600385/62300881-ee007680-b44d-11e9-93b5-1c5b49f641df.png) But: ![image](https://user-images.githubusercontent.com/18600385/62300941-096b8180-b44e-11e9-8bbe-cffad427f3d4.png) One might think: it's indexing Mon and Console separately, but with other words it works half-fine: ![image](https://user-images.githubusercontent.com/18600385/62301124-5e0efc80-b44e-11e9-9bfa-a231ab5752ba.png) Here the .h definition is correctly found, but the corresponding .c implementation is not.

GiteaMirror commented

2025-11-02 04:46:11 -06:00

@guillep2k commented on GitHub (Aug 2, 2019):

I made some tests, and the culprit is here, in modules/indexer/repo.go. It's explicitly calling for a camel case converter in the token_filters slice:

I'm sure there are cases where this is very much the desired behaviour, but it surely isn't what I was expecting. I tried removing camelcase.Name from the list and it's working for me, now.
A switch to choose the desired behaviour could be implemented as a setting in app.ini, but the previous indexes must be dropped and recreated if the setting is changed after the fact. An option to re-build the repo indexes in the Maintenance Operations section of /admin would be handy.

@guillep2k commented on GitHub (Aug 2, 2019): I made some tests, and the culprit is here, in modules/indexer/repo.go. It's explicitly calling for a camel case converter in the `token_filters` slice: ![image](https://user-images.githubusercontent.com/18600385/62347331-bc2ff400-b4cf-11e9-866a-c11ccfa54837.png) I'm sure there are cases where this is very much the desired behaviour, but it surely isn't what I was expecting. I tried removing camelcase.Name from the list and it's working for me, now. A switch to choose the desired behaviour could be implemented as a setting in app.ini, but the previous indexes must be dropped and recreated if the setting is changed after the fact. An option to re-build the repo indexes in the **Maintenance Operations** section of **/admin** would be handy.

GiteaMirror commented

2025-11-02 04:46:11 -06:00

@mrsdizzie commented on GitHub (Sep 7, 2020):

Should be fixed from #7733

@mrsdizzie commented on GitHub (Sep 7, 2020): Should be fixed from #7733

GiteaMirror referenced this issue

2025-11-02 12:13:32 -06:00

[PR #2736] [MERGED] Fix IE unsupported javascript construction in branch dropdown #16564

Sign in to join this conversation.