When changing Preferences, Low-Level Property "refresh.scanIntoSubmodules" to "false" -- does that resolve the problem?

Are the submodules registered/tracked (i.e. exist for all users) or nested roots (i.e. only exist for you)? What exactly is slow with these large submodules: initial scanning of the repository, refreshing, pulling, switching branches, ...?

So you want to find all commits for a specific day? To me it sounds more like searching a range would be good here. Also, are you interested in "Author" dates or "Commit" dates?

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

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.

It it not run in the main thread, otherwise you would not be able to perform any UI operation while the search is running.

> One use case is you want to add a specific things from the arbitrary commit. and not bring all changes from that commit like git cherry pick. Go over file by file and add the specific things.

In general this won't work well with a Working Tree - Commit comparison because this diff will include all changes between Working Tree and the commit and not only the commit's changes as patch, rewritten to the working tree, i.e. what a cherry-pick will do. It will be easier and safer to cherry-pick the corresponding commit without committing the cherry-pick, then use e.g. the Index Editor to unstage unwanted changes.

What about the internal Changes view, internal Compare -- do they work? If you still can't get it to work, please setup a small, public test repository (e.g. at GitHub) for which we both can reproduce the problem.

I understand, but I doubt that it's a good idea because it will become too easy for users locking too much (or even the entire repository).

I'm not sure whether we really want to support locking of folders. Hence, I have reduced the topic to "multiple files" only. If you think folder locking is important enough post another topic for folders.