SmartGit release notes (for each build in Preview) is in the form of a text file.

Visual Studio Code's release notes includes a gif to explain new features.

Can SmartGit do the same, but showcasing new features in the blog?

With a lot of active development and pull requests, branches I checkout/use/leave unattended/etc. can remain.  Having a quick indicator showing which ones do not have a remote branch hint that I can remove them.

It used to be quicker to know which branches don't have a remote but are tracked (remote was deleted) when hovering over a branch name and the tooltip shows "this branch is tracked but no remote branch exists", but 18.2 truncates the message and user must press F1 to see rest of message.

So when there is an update it says Restart/Remind Me later.  I kept putting it off with the Remind Me later because I was busy with other stuff and Thought by Restart it needed to do a full restart of the computer as many programs need to restart the computer on update.  Perhaps change the wording to Relaunch or Update.

When create a new branch, add one more textfield Branch Prefix.
So I can type here, for example, "UniversalSet".
Then each my commit to this branch get automatically prefix [UniversalSet]:

TODO save this to remove GIT server also, so other developer commits also will be prefixed.

yes possible todo prefs:  Add Branch Prefix.

yes it can be empty

Currently, if I click on and drag a branch label, it shows the label being dragged by the cursor, which is great as it makes absolutely clear that I'm dragging a branch label. When I drop the label, I get a popup menu such as the following:

But, only the first item has anything to do with dragging a branch; the other items relate to dragging the original commit of the branch. For example, if I drag the commit that the branch is attached to, I'll get the following:

If I wanted to drag the commit, I could have easily dragged the commit, and clearly SmartGit knows that I wanted to drag the branch label. Is there a reason why the "Cherry-Pick" and "Rebase" items need to be shown when dropping a dragged branch? And, if not, would you want to get rid of the menu altogether, and just let the branch be dragged? (It may be too irrevocable an action to not need a confirmation, as the original commit may no longer be easily accessible.)

Please remember manual proxy settings ('Host' and 'Port' of "Use following proxy").

When scrolling the Changes-View the scroll speed depends on which side hase the focus (clicked with mouse) and on which side the mouse is currently scrolling.

When focus and scrolling is on the same side (focus is on left side and mouse currently is over left side when scrolling) then the scrolling speed of the changes is equal to scrolling speed of mouse.

When focus and scrolling is on different sides (foxus on left side and mouse currently is over right side when scrolling) then the scrolling speed of the changes is way smaller than the actual scrolling speed of the mouse.

Either make it that scrolling the mouse scrolls the focused side or switch to focus, so that scrolling speed of the changes is equal to scrolling speed of the mouse.

In older versions, dragging a branch tag in the Commits window would pop up a dialog letting you choose between actions such as "Set <branchname> to <targetSHA>", "Cherry-pick", and the like. Now, there's a new, simpler popup menu with the choices, and it's easier to use.

In my experience I always use dragging to move the tag to the target commit; I've also noticed that this is the top choice in the menu. However, the menu is placed so this top choice isn't yet selected; you have to move the mouse after you drop to choose the item and before you click to choose it.

It would be great if the menu popped up right under the mouse, so that a second click would immediately move the tag. Yes, that may be hazardous in that unaware users might accidentally make the default choice, but they could always drag the tag back.

I use the git command can get the Title + Description commit about this:

    git commit -m "Title" -m "Description ......"

effect:

Log:

Can you help integrate into the UI?

When a Git command fails it is currently only reflected in "Output" window. I propose to make an option that would be making Git failures "loud" - for example by displaying an error window. That would guard users from forgetting to perform certain actions on their repositories because the commands failed silently - for example forgetting to push a tag or a branch.