Dear SyntEvo,

I would like to express my appreciation for SmartSynchronize. While I understand it is foremost a diff tool, for me, it has become an indispensable file manager in my daily workflow on Linux. SmartSynchronize (as a file manager) strikes a perfect balance between simplicity and functionality.

However, I've encountered an issue that I believe could enhance the user experience. The navigation bar struggles to handle long paths effectively. Navigating through extensive directory structures is a routine part a programmer's job. Unfortunately, the current design falls short when dealing with paths like:

/build/workdirs/projname-branch-server-native-gcc11-linux-libgen-customer/src/module/submodule/dir/subdir

When I delve into deeper directories like module/submodule, the navigation bar truncates crucial parts of the path, forcing me to rely on memory to recall my location (twice - there are two panels).

To address this issue, I propose two potential solutions:

• to display the end portion of the path instead of its beginning, offering a clearer indication of the current directory; and
• to mplementing a tooltip feature that provides the complete path when hovering over truncated segments.

Combining both approaches would undoubtedly provide the optimal solution. Nothing beats a good tooltip, though. ;-)

Once again, thank you for your attention to this matter and for the continued development of SmartSynchronize.

Best regards,
Peter

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.

Hey SmartGit folks,

I've been thinking about a couple of tweaks that could make SmartGit even smoother for everyday tasks. First off, how about a quick shortcut for amending commits? Right now, we have to tick the "Amend" box in the commit dialog, which is fine but a bit slow if you're doing it a lot. A single keypress or a direct button for this would be super handy.

And for those times when we're just fixing up a single file and want to amend it to the last commit, wouldn't it be cool to have an option to do that without the commit dialog popping up? Like, right-click the file and choose to amend commit directly—using the last commit message as a default. It would streamline those quick amendments.

What do you guys think? Could be some neat quality-of-life improvements, right?

Cheers!

Find a text in all changed files of a change-set. In a million+ code lines project some text might appear thousands of times, but you're only interested in the places of files you applied changes to. Add a checkbox to specify that only lines should be found where a change happened.

With that, if you have a huge change-set (e.g. 100+ files), you're able to track down a specific change (that may be problematic) much faster.

Add a check box in the garbadge collector popup to be able to fully clean a repository with a single pass on "Local" menu.

or a low level property to run "lfs prune" when the prune checkbox is selected.

Add ability for Squash in log view to work for non-consecutive commits. In that case smartgit would run a rebase that does the following:

- reorder selected commits so they are consecutive

- then squash them

If there is an merge issue then smartgit drops into interactive rebase step so use can resolve (or cancel).

This feature is the same as a function of the GitToolbox plugin for IntelliJ

Thanks and regards!

With github calling new master branches "main", the application is a bit confusing when setting up the feature branch flow option as it asks for "main branches".

Further more and even more confusing, when you come to finishing a feature, on the Finish Feature dialog, the first radio option is "Finish to main branch". This should state the name of the branch selected at feature setup as "main" is now confusing.

In my case I'm using the "develop" branch for all developments and "main" for production in line with Git-Flow process. As you can imagine being told each time that I'm finishing to "main branch", when in reality I'm finishing the "develop branch" (even though this does happen behind the scenes) is a bit disconcerting. I appreciate the text sub text at the top of dialog states the "develop" branch, but at quick glance it would be better if the radio also showed this.

If would be ideal at setup to request "derived branch(es)" rather than "main branches" or something similar, and then on the Finish Flow dialog, show the branch name you selected at setup that you are actually finishing to.

Thanks.

Though it is possible to edit commit author, it's impossible to set my data without preserving it somewhere or writing off from memory. Since SmartGit knows my data, it would be great if it allowed to use it for author editing.

Possible implementations:

• a new context menu item: "Change Author to myself";
• a checkbox or a button "Fill my data" in the "Edit Author" dialog.