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.

Would be nice to have a option to clone a new repository 'light' (git clone --depth=1).

Even better an additional option 'fast start' after depth=1 clone, smartgit can fill up the history slowly in the background, while people can work on the code already

Similar to http://smartgit.userecho.com/topics/353-when-creating-a-new-feature-gitflow-get-the-user-the-opportunity-to-select-jira-ticket-as-branch

It would be very useful to configure default option for feature finishing with git flow.

Configuration may implicit (e.g. in configuration file) or explicit (e.g. remember the last option used.

Quite often, I just want to view a git repo quickly and without saving it to the list of the repos in smartgit. It will be a lot efficient for my workflow to be able to just start smartgit from the command line and start browsing the git repo (and then forget about the repo).

Note that this can already be done using system properties: https://www.syntevo.com/doc/display/SG/System+Properties#SystemProperties-Journal