Search - Find in all history and not only displayed commits

[thmatot]

Describe the Bug
When I search an old commit message I have 0 result unless I scroll down and commit appears on screen.
Then search find 1 result

Expected Behaviour
Search is perform on all commit

[mhutchie]

Hi @thmatot,

The current behaviour is exactly by design and as I intended. The Find Widget allows the user to quickly jump through the loaded commits based on a simple search criteria matched in: the commit message / date / author / hash, branch or tag names. It is not designed to search all commits in the entire repository, as matches could be on commits that are on branches the user has deliberately filtered out via the "Branches" dropdown - in which case the extension could only respect the user's branch filters, or the user's Find criteria, not both. Additionally, if I were to change the Find Widget to return every match in the entire repository, in large repositories with a weak Find criteria the extension could load tens of thousands of commits - not what the user was wanting.

The Find Widget functions entirely in the extensions front-end, and does not run any Git commands. This is consistent with the vast majority of "Find" widgets I can think of across many applications, which allows the user to jump between matches in the loaded content (e.g. find on page in web browsers & files in vscode) - they rarely (if ever) load more content than what is already displayed.

However, there are some open feature requests to expand the existing branch filtering to be a far more generalised filtering capability (including authors, files, sub-directories, messages etc.). This filtering capability will integrate directly with the underlying Git commands that are used to retrieve commits, and would avoid both issues I mentioned in my first paragraph (along with many others). This will enable you to achieve what your currently expecting the Find Widget to do.

I'll close this issue, as the behaviour you've describe is by design, and the underlying functionality you're referring to will already be implemented in other open feature requests.

FYI: Depending on your repository, you may be able to use the Initial Load Commits Extension Setting to increase the number of loaded commits, and consequently the number of commits that the Find Widget operates on, until the advanced filtering capability is implemented in Git Graph.

[thmatot]

I agree with "It is not designed to search all commits in the entire repository, as matches could be on commits that are on branches the user has deliberately filtered out via the "Branches" dropdown"

But currently commit in the same branch (I only scroll down) is not found, which is a bug as user didn't filtered it.

But if you want to close this ticket because initial design doesn't allow to search on not loaded commits I understand.

[mhutchie]

Hi @thmatot, Thanks for your response.

Ultimately the reason for closing this was that the Find Widget is not designed to search the entire repository, only the loaded commits. The expanded filtering capability will be coming soon, and I definitely want to allow entire repository searches from it. There are numerous behind-the-scenes reasons why it makes far more sense to have these two capabilities independent of each other.

FYI:

But currently commit in the same branch (I only scroll down) is not found, which is a bug as user didn't filtered it.

I understand that in your specific scenario the commit is far enough back historically that it is just not initially loaded without scrolling, instead of being on another branch that has been filtered out, however there is no way for Git Graph to know that unless it loads every commit in the entire repository into memory and it performs its own tree traversal. This is just not a feasible solution, as a significant number of users have repositories that are extremely large. I purposely try to make Git Graph be as responsive and fast to load as possible.