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.

I was trying to set up my Hosting Provider, and kept getting a simple "401" error message.  My password is correct.

I switched to SourceTree to try out the same thing, and it let me know what was going on.

Can SmartGit do the same?  That would have saved me 15 minutes of retrying :)

A common operation in SG is to right-click on a specific file and choose "commit". This stages (if necessary) the specific file and prepares to commit it. 

However, if other files are already staged, they will be added to the commit even if that was not the intention. This fairly frequently causes accidental commits in our codebase, because the user assumes SG is going to commit only the selected file, but ends up committing other staged files as well because they forget to double-check the pre-commit dialog.

This is particularly common when lots of files are modified, because that can result in some staged files being "offscreen" in the "Files" window at the time the user selects the individual file. 

SmartGit already has a similar warning when someone is submitting "staged modified" files (to ask if only the staged changes should be submitted, versus all changes), so there is precedent for this kind of helpful warning.

Example: In the image below I right-clicked on the highlighted .gitignore file to commit it. If I am in a rush and forget to check the pre-commit dialog, I'll accidentally commit 3 files instead of one.

** Alternately (and perhaps ideally) SG would just disable the "submit" button when right-clicking a single file when other files are staged but not selected. This would prevent the problem entirely.

It would be nice to include tag information into commit message when merging from tag, something similar to the following:
"Merge tags/26.28.1(commit '9cfa861e02986dbed18dc83a3b3397699e3a4baf') into master"

If there are multiple tags behavior could be the same as for branches - use the first one from the list

When trying to understand the history of a change, it's common for someone to open the log window and then click back and forth on different commits to see what changed in them.

Currently, when the user clicks on a commit, the differences pane in the log window switches to display the file that is at the top of the Files window based on the current sort order. This makes it cumbersome to switch back and forth between commits to see what happened to a particular file because, unless that file happens to be at the top of the sort order in each commit, the differences pane keeps jumping around between files.

As an example, attached are two screenshots of what happens to the view when I switch between two changelists, both of which contain the same file "DBExternalViewManagerImpl.inl". 

I click on first commit and select DBExternalViewManagerImpl.inl in the files window:

Then I click on next commit in log; DBExternalViewManagerImpl.inl does not remain selected in files window, and the contents of the differences pane therefore change:

What I think the behavior should be is:

1. the file selected in the current commit should remain selected when switching to another commit, so long as the other commit contains the same file.
2. when switching to a different commit that does not contain the same file, it should switch to either:
• The file that was selected most recently for this commit
• Or the file at the top of the sort order, if no file was previously selected for the commit

#1 is the most important. #2 would really help when skipping around through multiple changelists that may not all contain the same files, but I understand that it would require a tiny amount of state tracking and may not be as easy to implement as #1.

Thanks for considering this request.

(Note: I filed this several years ago via email and it was filed internally as SG-9991. Since I cannot find it here on userecho, I have assumed it got "lost" and am re-filing it)