Present in 25.1.054 Preview build. For details, refer to:

• https://docs.syntevo.com/SmartGit/Latest/Manual/GUI/Notes
• https://docs.syntevo.com/SmartGit/Latest/Manual/Integrations/GitNotes-Integration

How important are your notes? How prominently should the icon be placed?

Option 1

Option 2

Option 3

What is the exact content of these notes? I'm wondering whether they should show up inlined? See "SUCCESS" and "FAILURE":

For 24.1 build 21152, Preferences, Low-level Properties "hobbyLicenseCheck.skipPublicRepositoryVerificationConfirmation" can be used to skip the confirmation dialog.

For version 25.1.021, we have implemented a new approach to this topic: rewording commit messages after the commit has been made (i.e., zero waiting time for the commit operation). It's quite tricky and experimental, as always :)

https://docs.syntevo.com/SmartGit/Latest/Manual/Integrations/AI#commit-message-rewording

For the Standard window, My History only shows pull requests that are relevant to you (as the Author/Assignee/Reviewer). There is currently no way to see all pull requests, and we are wondering whether a GUI client is actually the right place for this kind of overview. It's true that we have this feature in the Log window (but that doesn't necessarily mean it's ideal). Personally, when I need to manage pull requests, I switch to the GitHub Project instead (2 clicks in SmartGit) and continue there.

Here is a sample repository which uses "pdftotext". It should work out-of-the-box (tested on Windows):

textconv.zip

> A release branch would mark the start of the release process for a certain version and contain any changes on the way  to the actual release. When the release is done, the commit containing the sources for this version gets a tag with this version number and if there is a stable branch, it's fast-forwarded to this commit at the same time.

Is that close to what you are doing?

Exactly.

> 

The difficult part is merging those changes back into the development branch (since merging always has the potential to break things).

I think this could be separated from the release process, which means the release tag will always be on the last commit of the release branch. Any commit on the release branch might be merged into the development branch and in most cases the last one (containing all changes up to the release point) should be merged sooner or later to make sure you don't loose anything (but of course there might be exceptions to this rule).

That's also exactly what we are doing.

> I don't understand why tags are considered more "heavy-weight" than branches.

I have the following in mind: "main" represents the latest released/deployed version. And once you want to make a new deployment you simply move main a couple of commits forward. At certain milestones, when you make your deployment more public, you may in addition to that create a release-tag.

> Please feel free to rename this subject to attract more participants. It might help to get more input from other developers to see their needs.

I have done so now.

Thanks again for your detailed ideas!