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.

For those of us who contribute actively to opensource projects based on forgejo(for of gitlab) platform, i.e. codeberg, it would be nice to have some sort of integration, i.e. referencing issues, query issues, list pull requests, etc.

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.

Similar to this RFE : https://smartgit.userecho.com/communities/1/topics/1129-log-view-open-multiple-submodules-at-once

But for Repositories View.

It is something that I always missed something similar to what existed at SmartSVN.

Before submitting a code change to review, I usually try to clean it up and make sure the commits that make up the change make sense individually. During clean-up, I sometimes need to split commits, so the change could have ten or more commits waiting to be polished. At this time, it's sometimes difficult to keep track of which commit does what.

This work would be easier if commit graph would highlight the commits that affect a specific file.

What I have in mind is workflow like this:

1. Select a file in Commit / Files dialog.

2. Each commit that touches this file gets highlighted in Commit Graph.

The feature should be optional via Commit Graph hamburger menu.

Another variant of the same feature would add vertical lanes for the modified files in Commit Graph. Lanes would form a table with commits as rows, files as columns, and in each cell whether the commit modifies / deletes / adds the file. This would be more complex solution and might become cluttered if there are lots of files affected, so there should be a limit.

There should be following root categories:

• "Local Branches"
• one root category for each remote
• "Tags"

The explicit root nodes for each remote could also allow Remote-related operations (like in the Log window).