SmartGit integrates GitHub workflows in various places, provided that the connection to github.com or a custom GitHub Enterprise instance has been configured in the Preferences.
To set up the GitHub integration, go to Preferences, section Hosting Providers and use Add there. In the Add Hosting Provider dialog, have GitHub selected and invoke Generate API token. This should open up your default web browser where you will have to confirm by Authorize Application. Be sure to also Grant Access to all of your organizations, otherwise the corresponding organization repositories won’t show up/can’t be accessed.
Once you have confirmed this page, you will be redirected to syntevo.com, where the generated access code will be displayed. Copy&paste this code into SmartGit’s Generate API Token dialog and invoke Authenticate. The code will be used to create an application access token which will be used to populate the Token field.
By default, Use OAuth token for repository authentication will be selected. This will return the generated OAuth-token when Git asks for credentials (username + password) when connecting to your GitHub repository. Using the OAuth-token has following advantages:
- its scope is more limited than plain password or possibly more powerful personal access tokens
- it will not require to create/enter a second set of credentials to SmartGit
Finally, confirm the Add Hosting Provider dialog using Add.
Once you have authorized SmartGit, it will show up in your GitHub Settings, section Authorized Applications. If you need to rerun through the Authorization process outlined above, you have to Revoke access there first and start over.
When cloning a repository, you can select your repository from a list, instead of entering the URL. SmartGit will display your own (user) repositories, as well as repositories of your organization (org).
The main window contains a light-weight GitHub integration which just indicates incoming pull requests in the title of the Branches view.
Detailed pull request information and operations on pull requests are only available in the Log (see below).
In the Log window of your repository, you can interact with GitHub in following ways.
When initially loading the Log, SmartGit will also refresh information on related Pull Requests from the GitHub server:
- Incoming pull requests are those which other users are requesting to pull from their repositories. They are displayed in a separate category called Pull Requests in the Branches view.
- Outgoing pull requests are those which you have sent to other users/repositories, requesting them to pull your changes. They are display directly below the local (or if it does not exist), the remote branch in the Branches view.
Incoming pull requests, in first place, are just present on the server. SmartGit learns about them only by calling a GitHub REST API and displays the retrieved information in the Branches. To work with these pull requests (e.g. to review their commits, or Merge or Reject them), you first have to fetch them by invoking Fetch Pull Request from the context menu of the pull request. This will fetch all commits from the remote repository to a special branch in your local repository and will create an additional, virtual merge commit between the base commit from which the pull request has been forked and the latest (remote) pull request commit.
When selecting this merge node in the Commits view, you can see the entire changes which a multi-commit pull request includes and you can comment on these changes, if necessary. After commenting changes, it’s probably a good idea to Reject the pull request to signal the initiator of the pull request, that modifications are required before you are willing to pull his changes. If you are fine with a pull request, you may Merge it. This will request the GitHub server to merge the pull request and then SmartGit will pull the corresponding branch, so you will have the merged changes locally available.
Outgoing pull requests can be Fetched as well, however this is usually not necessary, as the pull request belongs to you and it contains your own commits. If you decide that you want to take a pull request back, use Reject.
For a pull request which had been fetched once, there was a special ref created which will make it show up in the Pull Requests category, even if it is not present on the server anymore. In this case, you may use Drop Local Data on such a pull request to get rid of the corresponding ref, the local merge commit, all other commits of the pull request and the entry in Pull Requests as well. It’s safe to use Drop Local Data, as it will only affect the local repository and you can re-fetch a pull request anytime you like using Fetch again.
You can invoke Review|Sync to manually update the displayed information. Usually you will want to do that, if you know that server-side information has changed since the Log has been opened.
To create a pull request, use Create Pull Request from the context menu of the Branches view.
GitHub allows to comment on a commit itself or individual line changes
(diffs). Comments can be applied to a commit or to a Pull Request.
Pull Request Comments will be refreshed together with those pull
requests which are locally available (see Fetch Pull Request above).
Plain Commit Comments will by default not be refreshed for performance
reasons. To tell SmartGit to fetch plain commit comments, too, configure
github.commitCommentPageLimit in the Preferences, Low-Level
Both, Pull Request and Plain Commit Comments, can refer either to a commit itself or to a specific line in a file:
- Commit comments will show up in the Commits view.
- Comments on individual lines will show up in the Changes view and the affected files will be highlighted in the Files and Commits view, too. This works the same way for line-comments of Pull Requests, provided that the pull request has been Fetched and the local pull request merge commit has been selected.
Comments can be created, modified and removed using the corresponding actions from the Comments menu or context menu actions in the Commits and Changes view. If a pull request merge commit is selected, only line-comments of the pull request can be manipulated.
More behavior of the GitHub integration can be customized by Low-Level Properties.
Sometimes you may need to rerun the OAuth setup, e.g. if a more recent version of SmartGit will request additional scopes. Usually, it’s sufficient to just open Preferences, section Authentication, open the GitHub hosting provider and invoke Generate API token there. If this does not solve your problem, take following steps to rerun the OAuth setup from scratch:
- In SmartGit:
- get rid of all GitHub-related credentials from Preferences, section Authentication
- get rid of the GitHub hosting provider from Preferences, section Hosting Providers
- In GitHub, open your profile Settings, Applications,
tab Authorized OAuth Apps:
- Select “SmartGit” there:
- Invoke Revoke Access
- Select “SmartGit” there:
- In SmartGit, rerun through the OAuth setup again:
- open Preferences, section Authentication
- Add a new GitHub hosting provider, as described above
Possible Problems & Solutions
Authenticating with two or more accounts
SmartGit currently does not support having two Hosting Providers configured for “github.com”, hence for the extended integration discussed above, you have to decide for one of your accounts. It’s however possible to access repositories of multiple GitHub accounts, as explained below.
If you want to authenticate to your GitHub repositories, using two or more accounts, open Preferences, section Hosting Providers, open the GitHub hosting provider there and deselect Use OAuth token for repository authentication. When pulling/pushing a GitHub repository for the next time, SmartGit will ask you for Username and Password. For the Username, just enter the appropriate GitHub account name, for the Password it’s recommended to generate a new Personal Access Token in your GitHub account settings (the repo scope needs to be selected).
Depending on your Git configuration, Git might request credentials only per-domain instead of per-repository. If so, try to reconfigure:
git config --global credential.github.com.useHttpPath true
Private repositories do not show up/403 when trying to access an organization repository
If you are authenticating using OAuth and you can’t see private repositories of your GitHub organization or pushing to your organization’s repositories fails with HTTP error code 403, make sure that your organization allows Third-party access and SmartGit is Approved. Your organization settings might look like this:
Note that the screenshot above shows the interface of the organization’s
manager. If you are not the manager, but just a member of the
organization, you can request access for SmartGit to this organization
from your Settings - Applications, tab Authorized OAuth Apps:
select SmartGit here and check for which organizations you may
request access. The screenshot below shows
syntdev2 for which access
can be requested. Once done so, the organization manager will receive a
notification and may confirm.
If your GitHub hosting provider is already set up in the Preferences and you need to rerun through the OAuth setup, as explained above.
Git-Flow Pull Requests will be closed on Finish Feature
When using Git-Flow or Git-Flow Light in combination with pull requests, pull requests may be marked as Closed instead of Merged after invoking Finish Feature. This happens when you have Delete Feature Branch selected for the Finish Feature dialog: with this option selected, the local and remote feature branch will be deleted immediately, however the resulting merge/rebase has not yet been pushed. If a branch will be deleted before it has been merged, GitHub will mark the pull request as Closed. If it’s only deleted after the branch has been merged, it will be marked as Merged. If you don’t want your pull requests to become Closed, unselect Delete Feature Branch, push the resulting merge/rebase first and only then Delete the feature branch from GitHub (e.g. from the Branches view).
Push fails with OAuth ‘scope’-related warning
From time to time, GitHub may introduce new or change existing OAuth permission scopes. In this case, SmartGit’s OAuth token may stop working. The solution is usually to rerun through the OAuth setup, as explained above.
Be sure to always try with the latest SmartGit release because we are regularly adjusting required scopes for the latest version. If you suspect that not even the latest version is requesting the scopes which are required for your scenario, you may manually change the scopes in the Preferences, Low-Level Properties, property “github.oauth.scopes”.
Typical Git error messages hinting to this kind of problem:
> ! refs/heads/some-branch:refs/heads/some-branch [remote rejected] > (refusing to allow an OAuth App to create or update workflow > `.github/workflows/some-workflow.yml` without `workflow` scope)