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.

Second thought: instead of "Merge", have "Continue". This would act just like the "Commit" button, and would continue the process of merging.

... am I missing subtleties?

I do exactly this (manually), and it's still slow, even when using command line git.

Clearly there shouldn't be a new, intermediate dialog whenever you choose Blame or Investigate.

So, two options:

• Have SmartGit respect the presence of a ".git-blame-ignore-revs" file at the top level (perhaps enabled by a config value)
• Have an "Ignore this revision" context menu choice that, when chosen, recalculates the Blame or Investigate's display without the chosen revision. The next time you open that revision's context menu, there's a checkmark next to the item; choose it again and the ignoring goes away. (Where would this config be stored?)

I'd also like this. If SmartGit could unambiguously detect that a) the file system was case-insensitive, and b) this was causing problems with Git-managed files that only differ by case, then showing a "Beware!" dialog would be very helpful. (Perhaps it could be made optional if it might happen too often in specific circumstances.)