Please, run that `File Content (very expensive)` search not in the main thread of Smartgit (causing it to make all other UI responses extremely slow).
Check out the repository: https://github.com/dae/anki
Open the log window and select `File Content (very expensive)` and search for `save_config`
After a few seconds, Smart will show all 5 results, but it will keep running the search for hours using 100 of a single CPU core:
The problem with it using 100% of that single-core, is that Smartgit will become quite slow to respond with everything it does.
Please, run that `File Content (very expensive)` search not in the main thread of Smartgit (causing it to make all other UI responses extremely slow).
Stop trying to be funny and pretending you do not understand by marking it as completed. If you are not mocking me, then you do not read my post. Of course, it is not running in the main thread of the UI (Graphical User Interface Eclipse Swing main thread), but it is on the "event loop" of the background tasks. If you look at the screencast I posted, the UI is responsive, but its requests to the background processor are extremely slow, taking several seconds to complete and show the git diff changes when I change the element on the UI.
Customer support service by UserEcho
It it not run in the main thread, otherwise you would not be able to perform any UI operation while the search is running.
Sorry, this was indeed a misunderstanding, I should have checked your screenshots in more details. Either way, what you are asking for is technically and even conceptually not possible: on one hand there should be a filter which populates the graph, on the other hand, it should be possible to continue working which can obviously affect the graph. I think this would open up an endless amount of possible UI/interaction problems.
If you reproduce the issue in your machine and play a little with it, you will notice that eventually, the background responds with the diff results requests while the search is running. This indicates that eventually the search "pauses" and the main background thread is free to return the diff results asked by the main UI.
I understand that if you allow writing operations to happens, this can complicate your implementation to guarantee correctness, but I am not asking to allow write operations, what bothers most is that I cannot browse/see right/properly the search results until the search is completed. For a big search as any search with `File Content (very expensive)` can be, it is very frustrating to wait several hours, perhaps days for the search to complete and only then properly see/browse the results. Seeing the results while they are showing up/right after they are found should be a must for a length operation as `File Content (very expensive)`.
While the search is running, access to the repository is "exclusively" locked as with all Git operations in SmartGit: user-visible "read-only" does not necessarily imply low-level (J)Git read-only. On a different level we have a dedicated worker-thread which operates sequentially and won't process operations while the filter is running. What you are suggesting would require to break at least one of these restrictions, probably both.
On the other hand, I doubt anybody is willing to sit and wait several hours to wait for SmartGit to complete the filter query without switching to other (Smart)Git tasks, including write-operations, too. Hence, I agree with you on the use case of doing a very expensive search in background but I disagree with the suggested solution.
I would probably just open a terminal, do the "git log" or "git grep" there [1] because I feel this is the better place than doing in an interactive GUI client. If we still want to have this functionality implemented in SmartGit, it should probably be a separate window which can be minimized and which will come back only once it has finished. And then there would still be the exclusive repository lock restriction which we had to give up.
[1] https://stackoverflow.com/questions/2928584
@Bugged This works fine in GitExtensions; while the search is running you can do anything with the results.