Please support working with Git-providers based on https://gogs.io/

Currently, the "Branches" pane shows a count of the number of branches in each top-level group (e.g. "Local Branches (3)" or "origin (27)"). And when "Group tags and branches by path-like name" is selected, there's a sub-group for each initial path component, with all branches having the same path component underneath that group.

Problem: we use path grouping for different developers, and some developers have gotten out of control on how many of their branches are still hanging around. But, it's hard to see which developer has lots of branches and which has few.

Suggestion: have the sub-groups display the count of branches within that sub-group.

Hi

while the font size of the SG application is configurable with the defaultSize ui low level props, the font size of the Merge request comments is apparently fixed and very small (the comments are almost unreadable). Is there a way to increase this font? If not, it should be possible to do it, please!

Thanks in advance

It would be great to run external tools on other contexts than the whole repo and files.

E.g., I like to manually prune remote branches. But for a repository with more than one remote, I cannot do this without using the command line because I cannot select the correct remote context to run my command.

Similarly, it would be great to also have tools available on branches and tags.

The easiest way for the user would be to add a "Tools" sub-menu entry on the context menu of the branches view items (and maybe the captions in the log graph).

This caption should similarly to the confirmation dialogue parse the replacements, so that the user can get a good description of what will happen.

For example:

label: "Prune remote branches of ${remoteName}"

command: ${git} fetch --prune ${remoteUrl}

Can we have fast-forward merge feature for branch in Standard workflow?

Hi,

I'm using a non-commercial license to access public repos. Every time I had to click to "verify this repo" - it is very annoying and unnecessary. If I'm using a non-commercial license, it's expected that I will keep only public repos inside SmarGit since I cannot open private ones anyway.

Please don't make the life of non-commercial users more difficult.

When you LKM on a file and click 'Log' - it shows filtered history with only commits that changed that file, but it doesn't show stashed changes. The 'Branches' menu in 'Log for <file>' window doesn't have 'Stashes' folder, while 'Log'  window does have it.

Occasionally, I need to review the code around a particular commit.
However, I can't seem to find a way to directly navigate to a particular commit without applying any filters.

I found it on gitkraken

but on smartgit

As an alternative to Specific word boundary settings for hyphen & underscore detection (https://smartgit.userecho.com/communities/1/topics/1685-specific-word-boundary-settings-for-hyphen-underscore-detection, if link doesn't review it means it's still being reviewed by moderation), we could add commands with customisable shortcuts to navigate per subword (separated by hyphen/underscore *even* if current word boundary setting skips them).

Default shortcuts could be Ctrl+Alt+Left/Right (may conflict with some desktops), or empty. Personally I'd use Alt+Left/Right but I'll have to remove existing competing shortcuts (in fact it's just Alt+Left that is mapped to reveal previous commit, others like File Compare: Take Left/Right Block are more contextual so it's ok).

In this case the best combination would be to set all boundary settings to skip hyphens and underscores (either via options as suggested in the thread linked above, or hardcoded to always skip if everyone agrees), and so users can navigate full words with Ctrl+Left/Right and then more precisely over subwords with the new commands/shortcuts.

And of course both suggestions are compatible: we could define behavior for Ctrl+Left/Right to the most useful ones for us, and use sub-word navigation when we need to.

This is a new request spawned from https://smartgit.userecho.com/communities/1/topics/1562-word-navigation-ctrlleftright-do-not-stop-before-and-after-every-space

Basically, word boundary has two modes based on:
Preferences > Low-level properties > styledtext.useOwnWordBoundaryDetection value

It affects both Ctrl+left/right navigation and double-click selection.

If true, SmartGit own detection is used

- stops at hyphens (not great for kebab-variables, but understandable for plain English compounded-words)

- skips underscores (good for snake_case variables)

- stops at left and right of spaces (annoying)

If false, system detection is used. For instance on Ubuntu 22.04 + Unity desktop I have:

- stops at hyphens (same as above)

- stops at underscores (may be annoying for snake_case variables when you don't want to edit them)

- stops only one at spaces (good)

In most cases I just want to navigate as fast as possible and skip underscores, stop only one at space and possibly stop at hyphens (e.g. in Python I don't use kebab-case so hyphens are just for compounded-words so it's ok to stop at them)

More granular options over how boundaries are defined would make it easier to get the navigation we want. They would only apply when styledtext.useOwnWordBoundaryDetection is true since otherwise system would take over.

Examples:

- styledtext.whenUsingOwnWordBoundaryDetectionStopOnceAtSpace (honestly I think this one should be true by default, and actually wouldn't even need an option to be false, not sure who would really use the "stop at left and right of space" case since in most cases you can just go to either side and press left/right)

- styledtext.whenUsingOwnWordBoundaryDetectionStopAtHyphen (currently true)

- styledtext.whenUsingOwnWordBoundaryDetectionStopAtUnderscore (currently false)

To be fair, if right now SmartGit's own boundary detection was "fixed" to stop only once per space it would be perfect for my setting, and there would be no need for options.

The options may be useful in different settings though.

You may survey other devs to decide whether a hardcoded change or full options (more time to implemented, but more flexible) is better.