I am not sure why I need to double click on it, because when I am selecting it (single click) on something, I already would like for it to open.

If the log view is restricted to a directory or file and only commits affecting this subtree are shown all review features are disabled. This makes sense for most of them like creating pull requests but it would be nice to be able to add review comments to commits and files even if the log view is filtered.

If I want for exmaple to review the changes of a specific Java package I would show the log for this folder. If I now want to make a comment I have to remeber the ID of the commit and look it up in the unrestricted log view. If I want to make a line comment I now have to select the file and scroll to the affected line and then add the comment there. A similiar case would be git blame where the log is automatically restricted to the file if I show the changes. The workflow would be more fluent if I could directly add the comment.

The auto stash feature is great when switching branches and a conflict occurs.

Regularly, I find that I want to apply the one or more stashed files with conflicts anyway, overwriting the workspace files.

I have not found an easy way of doing that; does one exist? 

If not, can we have an "Overwrite" option to Apply Stash?  This would work best with 642-cherry-pickrevert-allow-to-select-the-files-to-cherry-pickrevert on a per-stashed-file basis to limit to one file too.

When using the Working Tree window as primary environment, showing the current working tree state in the log again when using the "Log" button for a repo is not very helpful for two reasons:

1) This information is most likely the same that was present in the Working Tree window that opened the log

2) Selecting the last commit requires an extra step

3) SmartGit needs to assemble the list of changed / new files, although this information is most likely never needed coming from the working tree.

Therefore, it would be good to have an option to switch directly to the last commit. The working tree state still can be at the top of the list, but it should be possible that this is not the entry with default focus.

To be able to easily scan for significant commits or files, please:

1. Add to Log window columns for (Added Lines) and (Lines) similar to "git log --shortstat"; A graphical column as in "git log --stat" would also be welcome.
   
2. Same in Commit view for each file similar to "git log --stat" and "git log --numstat"

      3. Size of changes in KB would be great for scanning for large binaries, but I cannot provide a command line equivalent.

Currently they feel like 2 pixels wide and it can take some slow careful mouse movements to hit the right location (at least on windows).

Now, when an error occurs during pushing a pull request, the message is lost, and I have to retype it. This can happen easily, for example due to hooks.

Sometimes I accidentally add a file to a commit when I don't mean to. I haven't pushed the commit yet, so I'd like to be able to edit the commit and select 'remove file from commit'.

I really like how SmartGit is smart when doing pulls. If you say it to
merge, it will merge, if you say it to rebase, it will rebase. If
there are merge commits to be rebased, it will ask you about whether
you are going to preserve them. In a pretty annoying manner... It will
show this dialog box "rebasing a merge commit might easily cause
troubles, how about merge instead?".

But there are a number of problems with this dialog:
1. It does not say much. "Can cause troubles"? Huh? If I did not know
how it works, it wouldn't tell me much. Currently I know of only one
"trouble": if I have resolved conflicts in the merge I am about to
rebase, I would need to repeat it. Tell me this. Anything else? Tell
me either.
2. There is no way to select a default behavior. When I pull, I have
this nice little dialog, where I can select a default behavior: pull
or rebase. Why I cannot clarify rebase behavior in the same dialog?
Like rebase with preserve by default.

I use this feature very often in our workflow:

1. Create a dev branch. Develop it for some time.
2. Fetch. Checkout master. Merge dev into it.
3. Build and run tests.
4. Push to master. Discover there are new commits in master.
5. Pull master.
6. Push again.

On step #5 I don't want to pull with merge, because it will mess up my first parent path. But pulling with rebase, I want to preserve the merge to make it clear dev branch was merged. I am only rebasing this one merge commit. I never got into troubles with this approach.