If the rest of the MacOS search functionality worked then I'd be OK with SmartGit's search string not being shared with the rest of MacOS. So, the above, but the search string memory is independent of MacOS'.

This is still a significant issue. I use SmartGit's diff view to review my changes, and it's excellent for that. But, when I have to do any sort of searching, SmartGit's awkward tools force me to jump over to BBEdit, make changes, come back to SmartGit, and then reload the diff.

I came to suggest this, and found that I'd already suggested it.

A related item: if viewing a list of commits in the Graph view (even if one isn't selected) then showing/hiding branches and tags shouldn't scroll the visible commits off of the screen. Possible rules:

1. If a visible commit is selected, and doesn't disappear with the change, then maintain its position on the screen
2. Otherwise, find the commit closest to the vertical center of the Graph view that doesn't disappear with the change and then maintain its position.

A side note: I'd been using SSHFS with SmartGit since forever, but in recent months SSHFS for Mac has been abandonware, and has been getting less and less reliable. I finally managed to get NFS working to my remote machines, and I have to say that SmartGit over NFS is at least twice as fast as SmartGit over SSHFS. It's now quite useable; I never get the multiple-minutes-long lockups, and only once in a while have to wait longer than ten seconds.

This isn't a solution outside of my local network, though, so I still think SmartGit over SSH to a remote Git executable would add a lot of value. I'm much less blocked by it, though.

I just found the "Remove 'annotated tag' checkbox" RFE from March 2017:

https://smartgit.userecho.com/communities/1/topics/1836-option-to-always-create-annotated-tags

That's been completed for a long time, and I understand the problem that this was trying to fix, but I think the fix was the wrong one. Instead of requiring "Message" to have text before creating an annotated tag, you should be allowed to create an annotated tag with an empty message. So:

1. Restore the "annotated tag" checkbox
2. If "annotated tag" is not checked, disable the "Message" field
3. If "annotated tag" is checked, enable "Message" field, but do not require that it contain text. (I wouldn't even pop up a "You sure?" if empty; let's trust the developer.)

I'll suggest that the default for this property should be false. My experience is that SmartGit isn't very good at figuring out where new repositories should go, and I doubt that it could be all that good, given that users have so many different ways of naming their repositories and their SmartGit repository entries.

This problem has been bugging me for a long time (e.g. I'm now looking at a commit that's on 18 branches, and merged to 12). This fix works, but there's no way I'd have found this on my own.

Perhaps add it as a preference?

Good information. However, doesn't SmartGit technically have all the information it needs, since it knows the parent commits that were merged, and thus the two states of the two files being merged? So, it could open the Conflict Solver showing one parent on the left and the other parent on the right, maintaining the merged content, but without Git's underlying support.

(That said, I wouldn't be at all surprised if bypassing Git's merge system would be a complete PIA for Smart Git.)

Bump...

The "Commit" button in the toolbar, equivalent to choosing the "Local/Commit..." menu item.