Is anyone using subtrees to sync back and forth between your main repository and the subtree, i.e. a combination of "git subtree merge" and "git subtree split"? Which exact commands/parameters are you using here?

Did you use "git subtree add" command to initialize the subtree? If so, there should be at least an initial subtree merge commit containing meta information about the subtree, like:

git-subtree-dir: src/project
git-subtree-mainline: e7f09673067cd094778ed6089c8d4fe0756e73ca
git-subtree-split: 4dffc803a8f86d75d64c26fa5836c240048c9ebb

Based on this information, SmartGit can infer the subtree prefix and invoke "git subtree merge --prefix=<prefix>" which internally results in a "git merge -Xsubtree=<prefix>". This seems to be safer than "git merge -s subtree" which has to guess about the prefix and could fail.

Did you use "git subtree add" command to initialize the subtree? If so, there should be at least an initial subtree merge commit containing meta information about the subtree, like:

git-subtree-dir: src/project
git-subtree-mainline: e7f09673067cd094778ed6089c8d4fe0756e73ca
git-subtree-split: 4dffc803a8f86d75d64c26fa5836c240048c9ebb

Based on this information, SmartGit can infer the subtree prefix and invoke "git subtree merge --prefix=<prefix>" which internally results in a "git merge -Xsubtree=<prefix>". This seems to be safer than "git merge -s subtree" which has to guess about the prefix and could fail.

Which file contents should be used in this case? Given such a working tree state, can you give appropriate Git commands to retrieve these file contents?

I have updated the subject. Do you agree?

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