This will look just like how GitHub shows diffs

Example: https://github.com/git/git/commit/45ee13b942b26925b33d827bda2856e1ed0af0b7

Git 2.23 added a new "git switch" command for switching branches: https://github.blog/2019-08-16-highlights-from-git-2-23/#experimental-alternatives-for-git-checkout. This new name is much clearer in explaining what it does than "checkout" ever was.

I use "git switch" at the command line so often now, that when I come to SmartGit I have to spend several seconds scanning the branch context menu for the "Switch" command before I remember it's still called "Check Out".

SmartGit should adopt this new git terminology and use it in the SmartGit UI, as it's a clearer verb for what the command will do, and it matches the future of the git CLI.

We are coming from a centralized source control repository and adopting Git. One thing we loved about our old tool (SourceGear Vault) was that for our modified files, it showed us the difference of the modified file's size on disk compared to the current version in source control. This was helpful for us and provided some context on the size of the change we made to each file. 

For example if one file has +10kb of changes, then we know that is a significant change and should be reviewed closely before committing, where as a +1 byte delta would tell us it was a trivial/minor change to the file.

Having the ability to also sort on the file size delta was helpful to get the most significant changes (largest deltas) grouped together before committing, helping us see the biggest changes in one spot rather than sorted by filename or by folder. Sometimes we'd catch a 'console.log' statement in a file when sorting by size as well, as that change would be around +18 bytes to a file, which is easier to detect and remove before committing when sorting changes by size.

See screenshots for where this would be great in SmartGit, and how it is displayed in SourceGear Vault: 

Long time SmartGit user!

I've been using SmartGit exclusively for almost 10 years now, and over the course of time have accumulated access to almost 70 distinct source repositories related to/necessary for my job functions.  As a result, I'm heavily dependent upon the functionality that's provided by Repository Groups.

It would be helpful/useful to expand upon the attribute set currently afforded by Repository Groups, to include the following:

1. The ability to optionally specify (and edit) a short description or comment for the group.  This description could then appear upon hover over the group in the Repositories view.  (some of the "legacy" repositories and parent groups I maintain are used infrequently, and a tool tip that additionally helps to identify the purpose/intent of the Repository Group - and its subordinate repositories - would be helpful).

2. The ability to optionally specify (and edit) a color for the group, which affects the either the folder icon and/or text color of the group name displayed in the Repositories view.  (some of the "legacy" repository and parent Repository Groups I maintain are used infrequently, and a identifiable color that helps better distinguish Repository Groups from one another would be helpful).

Pull already lets you choose between merge and rebase as well as setting a default action. I propose an additional smart mode mapped to a separate toolbar button, which can be added to the toolbar and/or replace regular pull if desired:

- If there are no local changes...

-- ... and no local commits, fast forward without asking

-- ... and local commits, rebase without asking (optional warning, if there are a lot of incoming commits)

- If there are local changes...

-- ... and no local commits, attempt to pull with merge, on failure offer stash&retry

-- ... and local commits, warn user and offer to stash and proceed with rebase

As an user I'd like to be able to define background color label per git remote.

Right now graph window shows remote/branch labels with bright yellow background.

I'd like to adjust background for certain repos to make it more distinct.

This is a followup / extension to:

• Ignore file ability to specify which gitignore file to use
• Merge local gitignore file rules into root gitignore file
• Ignore dialog list users exclude file

Currently, adding new ignored files will be stored in a local .gitignore file (local to the ignored file / same directory). It would be nice if the default option for the destination dropdown box could be selected in settings.

Currently, I need to change the dropdown on every ignored file or pattern to .gitignore in the repository root.

Our use case for this feature is to retrieve and/or look at old

code that has been removed at some point in the past. Often we don't

know when it was removed and sometimes we don't even remember the name

of the file that we are looking for.The file could have been

removed by another user of the repository and they may not have put the

file name in the commit message. By getting a list of the files deleted

we can see the history of deletion and seeing the file names may also

jog our memory about what the name of the file is. Even with the name,

there isn't a way in Smartgit that I know of to find when the file was

deleted and by which user.For example lets say I delete a

class file from the repository that is no longer referenced or used by

our project. Another user, at a later time is looking for the file but

can't find it anywhere in the project and they would like to at the code

or use the code in something they are working on. They may a vague

recollection that it used to exist 6 months ago but at some point in

time between 6 months ago and now it was deleted. They would then have

to look at the log entry of every commit between now and 6 months ago to

find the deleted file. This could take a long time if there are lots of

commits. A list of deleted files would cut down their search time

dramatically.

Currently, the user can select multiple repos and perform the same action on all of them, such as pull. Instead of selecting the individual repos, please allow the same repo actions on the selected groups.

We're using a self hosted gitlab server instance using the community edition.

Using the integration with a Gitlab instances only allows us to see all projects granted access to me or seeing and creating merge request.

Since we're also using the gitlab issue tracker it would be great to add a better integration with the issues, e.g:

• Show Issue Numbers in log view that relate to commits (next to authors)
• Create issues prior to commits with a simple dialogue (for minor issues this would be great)
• Provide additional information during the commit to not only close an issues (gitlab automatically does this if wrting 'fixes #123') but also to label or assign milestones to it.