Steps to reproduce:

- open repo1 (double click it's name in a Repositories-panel)

- click "Recyclable commits"-checkbox in Branches-panel to show all recyclable commits in graph-panel

- open repo2 (double click it's name in a Repositories-panel)

- open repo1 (double click it's name in a Repositories-panel)

Expected: "Recyclable commits"-checkbox is turned ON

Actual: "Recyclable commits"-checkbox is turned OFF

Now you can right click a file in Files-panel and click "Ignore" to add the file to .ignore.
But it's not possible to add a folder to ignore.
I suggest to add option "Add folder to ignore". 
Or do not block slashes in pattern input textbox.
The reason why it is prohibited is unclear.

Even better - to add option "Ignore folder" to a folder menu here:

Parsing the `git rebase` command output and extracting the "Rebasing (x/y)` parts could be used to replace the infinite loading indicator with a progress bar in the status bar.

When ignoring whitespaces for line comparison, the diff view also ignores them in Java strings. Those should never be ignored.

I would consider that a bug. 

Add feature to seach by content in Files-panel.
Now it's only possible in Graph-panel.

Currently, you can only search within lines, but I sometimes search for multiple ones (a code block) in order to ensure whether it's duplicated in the same file or not.

Hi,

just a feedback, but IMO the naming scheme for the "updates" could be improved. I provide details as follows.

Under tab menu Help, one finds two options

• Check for New Version
• Check for Latest Build

At the same time, users receive notifications "XXX RC available".

Findings

Firstly, checking a "New Version" sounds like checking for an "overall" new version, which is translates like "Latest Build", but what it actually means is an increment of the currently installed version, right? Exactly that should be made clear. "New Version" means "Version increment of currently installed release".

Secondly, the "RC" translates to what exactly, the same as "Latest Build"? Then that should be made clear (harmonized) in the notifications or at the same time in the Help menu: "Check for Latest Build or Release Candidate". (Suppose both have the same meaning)

Thirdly, what is the numbers game behind all this: The "New Versions" are what, this: 22.1.7 #19285, or that 22.1.7 #19285? Then follows, what is the RC, a major increment, such as 23.0.0?

As a suggestion make it clear, what is going on to someone not using this every day and not so much caring about atomic updates. Which name implies which and what increments should worked out. Also, which updates float or de-evaluate the current license (if this is necessary in this context)? Does the license continue to work with RC "upgrade"? Provide the information first.

Kind regards

Hi.

Having catch myself multiple times doing double click on the repositories tabs in the standard window in order to close them (driven by the behavior on other S/Ws with tabs that I am familiar with) but with nothing happening, I'd like to ask for this feature.

Thus the idea is: "Double Click" on a repository tab = "right click + Close" over the tab.

Thanks

Hi.

Recently I made some work with tags in my workflow using SmartGit. To be honest, I found it hard to recognize them among many commits. Then I though to propose a feature : to permit users to set specific color for tags (i.e. I am using yellow color to be identified easily). And also providing an option to place tags first per row.

Then I tried to make an example for you to see what I mean. In the next figure, in left side, please find the tags (supposing you don't know them, or remember them). It's visually relative hard to find them, even in just 7 rows with just a few text (mostly because their color is similar to the remote branches). Imagine what happens in cases of more lines with much text per commit or multiple remotes.

Then I opened the test with another common program I use till now (where user can also set colors for different things).

Thus notice that Tags are yellow (and not gray as remote branches) and they are placed first (not last - depending on the remotes and the branches they may not be also visible due to lines length!). This placement (the second) gives priority on tags, both visually and by position, making them visible at a glance and ensuring they are always visible.

I can only imagine how the SmartGit view could be with the tags in frond with yellow/black background/foreground, and I have the impression this would be a better approach than it's now (but maybe I am biased due to by relative experience with such S/W).

Thus my proposal for enhancement regarding view of tags is:

1. Permit user to decide if he wants then at the start of each row, or at the end (as it's now)

2. Provide user the option to give color (background/foreground) to the tags.

Thanks