[mdindoffer]

Summary

This PR adds a "fulltext" search capability to perform a unified search across multiple commit fields at once, which was refused a year ago in #985 due to time constraints.

How & why

Git has no bult-in logical "OR" --grep/--author/--committer in a single invocation, so the new All method (now the default) runs the field queries separately, plus an exact-SHA lookup, and merges the deduplicated results sorted by commit time. Adds an internal-only ByCommitter query mode to power it.

Disclaimer

This was done with the help of Claude, as I have not done any C# development in the last 8 years. Feel free to reject on maintainability concerns.

[mdindoffer]

@love-linger Are you accepting pull requests? I tested this manually on my local build, I did not find any issues. What do you think about calling this option "All" if it does not include the path/content search? Should I rename it to something like "Metadata" instead?

[love-linger]

Sorry for the delayed reply. I do not think we need this feature.

• SHA/Author/Message/Path are totally deferent things. Usually, we are not unclear about the types that need to be searched.
• Doing this is unhelpful in terms of both time‑consumption and contribution to the results.

[mdindoffer]

Could you please elaborate on why do you think this is "unhelpful"?

I would argue this is a very nice usability improvement, for the justification see the original issue #985 .
You don't have to select what you want to search for, you just type your prompt. This is removing a huge annoyance. That's how search works in almost any software nowadays - Google indexes everything, Gitlab has also unified search for SHAs and content. In my internet banking website, when I'm looking at my account transactions, I don't have pick whether I want to search by IBAN/account number, or by the Name of the partner - I just type it into the search box and the IB app is smart enough to figure it out. Picking your search mode first is an artefact from the 1990s.

When you are searching for multiple "things" in succession you would have to always pick and select the appropriate item from the dropdown, now you finally have a fulltext search where you can copy&paste the commit SHA and the author email and so on.

The performance is OK, I tested this on a repository with thousands of commits, it was instantaneous.

Saving 2-3 mouse clicks per user interaction is a usability design win. When you look for UX best practices for implementing search functionality, they always mention a unified index is a cornerstone:

• https://whatifdesign.co/feeds/blog/best-search-ux-design
• https://moodymedia.io/blog/search-ux-best-practices/
• https://www.coveo.com/blog/search-box-ux-examples/

[love-linger]

I think I have explained it very clearly - it will take too long time. For example: with your PR, seaching a simple string leo in Unreal Engine repo will takes 10+ seconds (on AMD Ryzen 9 7950X + SSD). While only searching leo with AUTHOR or MESSAGE will only take less than 5 seconds.

[mdindoffer]

OK, I reworked the implementation.
Previously the search was being run sequentially in multiple git passes, that's why it took so long in scenarios with extremely long history and few matches (that don't hit the 1000 cap limit).

Now, it runs the search in parallel by awaiting on Task.WhenAll.

This should on a multicore system bring back the performance of the search on par with the other search modes.

@love-linger Could you please give this another chance?