Your comments

All I checked was that, from the O/S perspective, all the memory was actually committed and part of the working set, and does not change (materially) when invoking GC. Perhaps the Java VM is holding onto memory even if not needed by SmartGit, but from my perspective as a user of the product I just see excessive memory use.


Personally I would rather not have to deal with the details of the underlying language/runtime the product is based upon.


Its been two decades since I did significant work in Java, and I'm no expert, but would it be possible to reduce the memory allocations (temporary and/or long-term) done by SmartGit in general, so that the garbage collector has less to deal with in the first place?


If there's some logging or command I can run for you using the standard Oracle java client install, I'm happy to do that. But I'm not familiar with the current state of Java profilers so you'd have to tell me what commands you wanted me to try.

Yes, this request is for Blame, not DeepGit. As we've discussed privately over email, despite how much I want to love DeepGit, I always get lost navigating forwards and backwards in it. Blame is much more straightforward so I rely on that 99% of the time.

There's also a request to "Add "fast global search" capability for fast access to commit info and SmartGit commands" which sounds like it would satisfy this request.

In case this helps anyone, we finally tracked down what was causing the majority of our mix-up line endings. It was the git merge process, which does not respect git's autocrlf setting. We fixed this by adding the following to our .gitconfig


[merge]

## convert line endings during a merge (like autocrlf does during a pull/commit) to avoid line-ending-only conflicts

renormalize = true


We have some new team members who we're encouraging to migrate from SourceTree, and this is one of two missing features that is making it difficult for them to switch over to SmartGit (the other being this issue, which is already in progress).


So +1 on this item

It would be nice to have this functionality for cherrypicked commits as well.

I know this isn't the highest-voted request, but this just bit me yet again today. Any possibility of getting it into an upcoming build?

> Maybe it would be useful to split "Save Stash" into "Stash All" and "Stash Selection" (which could show the dialog)?


+1 for this. I find the current behavior a little confusing, because a persistent checkbox value in the stash dialog controls what is essentially a one-off decision (i.e. stash all or stash selected). Having separate options would be preferable to me.