Dispelling concerns about SmartGit’s automatic connection setup to your GitHub, Bitbucket or GitLab account

We have been contacted by a user who has concerns about the link setup procedure between SmartGit and Bitbucket (Preferences, Hosting Providers). While the procedure is actually inscrutable on first glance, following it step-by-step we can see that it’s safe with respect to the protection of your Bitbucket account:

As you can see from the Request Access Token dialog, your browser will directly open a bitbucket.org Link. If you prefer, you may copy&paste the URL yourself to your browser.

The URL is about OAuth authorization and specifies two parameters client_id and response_type which we can assume. We can assume that client_id is pretty much what it says: the Client ID of SmartGit — otherwise that would be a significant design flaw of the Bitbucket API for such a central end point. We can also assume that Bitbucket is very much interested in telling you exactly for which access rights the OAuth request is asking and that it would warn you about strange requests, to protect its users from malicious applications.

After confirming access, Bitbucket will pass an authorization token to Syntevo’s website. Again, we can assume that whatever this token is, Bitbucket considers it safe to pass on to the requesting application (the detour over syntevo.com is necessary because Bitbucket can’t pass the token directly to your running SmartGit instance).


File Compare: scroll between changes (Windows 10)

In SmartGit, SmartSVN and SmartSynchronize you can easily scroll from change to change by using the mouse wheel over the area between the left and right file content views.

On Windows 10 you need to enable a system option to make this working:

  • open Windows’ Settings
  • select Devices
  • on the Mouse page select the option Scroll inactive windows when I hover over them

Install a .deb bundle

You can install a Debian bundle using
$ sudo dpkg -i <deb-file>
If some dependencies are unmet like when installing SmartGit or SmartSVN, you can install them as well using
$ sudo apt --fix-broken install

Log vs. Working Tree Window

From time to time people ask us why we don’t implement the Log into the Working Tree window. The answer is: we have already done that the reverse way in version 18.2. Here we have added all working tree features from the main window (now called “Working Tree window”) which do not result in (conceptual) problems. Why is the old “main window” still there? Mainly, because it has been there since ever and contains certain functionality which (i) simply does not fit into the new Log window but (ii) which can’t be removed to not frustrate existing users. In short, these are

  1. open multiple repositories in a group and see all files of them, including their submodules in one view
  2. see the exact directory structure of the repository, including the position of the submodules
  3. have an optimized display of the current branch’s history and optionally of one additional branch in the Journal view
  4. show additional columns in the Files view that only make sense for the working tree: Size, Last Changed On

If one of the above points is important to you, you might want to stick with the working tree window. Otherwise, we recommend to make the Log window your main window (this can be configured in the Preferences).

Now in more detail, why the above features do not fit into the Log window:

  1. Combining the set of files from multiples repositories works fine, but already now, certain actions will be disabled and certain views (like the Journal) will go blank when having such a “meta-selection” of repositories. Combining log graphs can’t be done in a reasonable way and thus the log graph — the central component of the Log window — would go blank or only show the “WT/Index” nodes. This is not reasonable and hence we don’t provide selection of multiple repositories in the Log window.
  2. The Repositories view of the Working Tree window shows exactly the file system content. For the Log window, it’s not reasonable to include non-submodule directories in the Repositories view, because then the most intuitive expectation will be to limit the graph to sub-directory commits, too. However, this is problematical:
    1. Filtering Commits based on folders is a quite expensive operation and it will take significant time until the Log is populated. It may even take significant time until the first commit is found and reported, if the repository is large enough and the last commits for the selected directory are old enough. This will make the UI will look sluggish. Also, considering users which are navigating through the Repository tree using keyboard, this will put a significant load on SmartGit.
    2. Sub-directory Logs are seldom used, based on feedback we have received from our users. File Logs are more frequently used, but still rather seldom compared to the repository root Log. Thus, for users, which only want to invoke a command on the sub-directory, it may even be unexpected/unwanted having graph being rebuilt.
    3. Sub-directory and File Logs provide slightly different functionality (e.g. which operations are provided, which Branches categories are displayed), so the same Log window would have to behave differently when in “sub-directory” mode.
  3. The Journal view has developed over several SmartGit versions and shows the history in a way optimized for the current branch. The Log graph is no exact replacement for the Journal, hence the Journal must be kept somehow. Having Log view and Journal view present in the same window isn’t reasonable, though.
  4. The Files view is the central component of the Working Tree window and consists of many columns, for which only a few (like Name, State and Relative Directory) are interesting for the majority of users. Still, lots of other columns are available which either do not make sense for commit files at all or which would be too expensive to populate for commit files. Now, depending on the graph selection (WT vs. Index vs. Commit) we could switch visible and available columns of the Files view. But as most of the additional working tree columns are less important, we decided against providing them at all, in favor of a more stable and less fidgety GUI.