I like to have a clean history in my repositories and thus I do lot of rebasing and squashing on feature branches. And there is especially one task I do *very* often in the exact same way: Amend (parts of) local changes to older commits of the current feature branch because there was something missing/wrong in an older commit which I want to fixup now. This is my current workflow to do this:

- Stage changes which should be amended to an older commit

- Commit index into a (temporary) commit (with a random commit message like "asdf")

- Using drag&drop in the Journal, move the commit down the history, right after the commit to fixup

- Select both commits in the Journal and choose "Squash" from the context menu

This works pretty good (as long as there are no conflicts), but requires lot of clicks/typing/dragging every time. If I'm not the only one who often amends to older commits, it may be worth to implement a feature to make this easier ;)

Such a feature could look very simple: In the Journal, add a context menu item called something like "Amend current index". Then one needs to just stage the desired changes, right click on an older commit in the Journal, choose "Amend current index", and SmartGit would do the whole rebase operation.

It would be nice if the repo status icons (the "orange up" or "green down" icons) can be repeated at the taskbar level.  We just need to add these arrows in the lower-right quadrant of the taskbar icon.

As a maintainer, I would like to know something has changed while SmartGit is minimized.

I believe some media players to this as well, indicating the play/pause state in the icon.

See also: https://smartgit.userecho.com/topics/655

TL;DR: If the Log window had a Repositories view, switching between repos is as easy as on the main window, and does not require finding/launching and switching to the main window to do so.

I understand the design decision to have separate windows for the different macro activities, so this request is an idea that will help a lot with usability in that design and is possibly a reasonable answer for those that want a single window.

I often work on large products and they often have over 25 repositories; this causes a lot of switching between repos.  I use one main window and easily switch between repos; occasionally I open a second or third main window but not usually.

I regularly open a log window when needed on a repo to review commits/diffs.  This is the usability problem - having to find the main window, select the repo, and open the Log window.

In pane Repositories, next to a repository (also true for submodules) the branch that is checked out is displayed, and the tooltip shows additional information about this branch.

When HEAD is pointing to a commit (no local branch present; 'read-only' checkout), the information displayed is very limited, being the commit ID and commit summary. Also the tooltip shows only few information.

Instead of

    Repository_name (short_SHA: commit_summary)

it would be great to have tag information displayed here if present, e.g.

    Repository_name (chronological list of tags)

and move the

    short_SHA: commit_summary

to the tooltip. The tags could also be added to the tooltip, one per line.

With this information I would be possible to immediately see for a repository using submodules which submodule versions are used (assuming that the submodule commits have been properly tagged).

Horizontal scrolling is bad, so it would be nice if this window allows word-wrapping, just like the Output window in Visual Studio.

Example: current branch is branch1; want to checkout 'develop' but develop diverged and requires a pull (an extra step).

The idea is using an existing local branch that is already tracking it, not create a new local branch. (I do not want to checkout as "develop2" just because develop has diverged!)

Use cases:
- Submodules: Over time submodules can be changed (added/removed). This is not an operation that is well done when performing a checkout and submodules directories gets in the way when switching back & forth in history.
- PR workflow : PR systems often merges a PR branch to develop/master, locally switching from a PR branch that just got merged by such system to the latest "develop" would often yield near-zero change and would be more "friendly" with system that looks for changes on disk to "reload" pages and such.

- Optimization; large repo with long history:  switching to a branch that has diverged for a long time on a large repo can be very slow (because of the large number of files to change). Git needs to restore a very old state. In the case that the pull step would presumable restore the branch to a fairly recent state, then we could have saved us the heavy back&forth in history. From a Git standpoint, we could have saved lot of time by going directly to the other commit without going through a very old commit first.

Currently this case is already detected in SmartGit and a dialog with a few options are shown to the user. I think we could safely add another option.

Can you please add executable status to the column list and also properly detect it per file so that only one option shows up to either set or unset the executable bit instead of both?

please add syntax highlighting for CMake files

Currently the dialog offers two choices after the resolution is done:

- Stage: Mark the conflict as resolved and stage the file

- Cancel: Revert the file into conflicted state.

It would be nice to have a third option that will allow the user to mark the conflict as resolved and the file unstaged. I believe the Git command in this case is simply "git reset HEAD <file>".

In "Branch Coloring" mode, the log line of the branch is in bold black, while other branches are in soft gray.  To make it easier for the eye to scan through, the commit text of the other branches should be grayed as well.

However, grayed text is already taken up by merge-commits, so the change of behavior may be confusing for existing users.  But in my opinion, graying out a merge-commit doesn't mean much, and I would rather have the grayed behavior taken up by this RFE.