Tag: GitQlient

Deleaker review on GitQlient

Today I’m going to change the subject a bit! Even that is still based on Qt it only touches GitQlient tangentially. This time GitQlient is the test environment and thing to show is the Deleaker review!

Artem contacted me a long time ago and my plan was to publish a post before the word pandemic became mainstream. Unfortunately, for obvious reasons I’ve had to delay it until I found time.

I never checked how GitQlient was doing it with the memory before. Mainly because I trusted Qt handling it for me. That’s fine most of the time but is also a bit error-prone since GitQlient is doing a lot of things. And not always they are under Qt’s radar.

Nowadays, I’m keeping GitQlient running more than usual. That made me realize that memory is really important so it doesn’t swallow all the RAM in the computer. During Christmas I finally found some time to go back to my Windows partition to test Deleaker with GitQlient.

After some time with it I think I’ve learned a bit about how it works. So here are some of my thoughts!

My setup

For the test I’m using Visual Studio 2019 Community, although Deleaker also works with Qt Creator and it has a really nice integration. I’m using all the allocation types because I wanted to see everything although in my case I was interested in the memory ones:

Using all Deleaker allocation types
Using all Deleaker allocation types

Running Deleaker

The first test I did was to run GitQlient, open a repository and closing it without interacting with Git at all.

Deleaker allows you to take Snapshots and that’s a really powerful tool I’ve used during the whole test. In Visual Studio, you just need to go to Extensions -> Deleaker -> Deleaker Window. In the top left you can see the option Take Snapshot and that’s the one I press every time I did a significant change.

For this Deleaker review I used 3 snapshots in addition to the last one that Deleaker automatically creates. After you take a snapshot, the stack trace will be available for you to dig into it. So there is no need to wait until the final execution and remember what each snapshot was about. After the very first snapshot I got the following stack trace:

First snapshot with Deleaker
First snapshot of Deleaker

This scared me a lot, because I wasn’t expecting to get so many leaks to start with. But I was wrong: when I took the snapshots, the objects are attached to the life of their parent widget. So, for now I don’t need to worry!

Snapshots

Next step was to open a repository, take a snapshot and right after that, close it taking another snapshot afterwards. This is a summary of the snapshots I took:

  1. After GitQlient starts
  2. Once a Git repository is open
  3. After closing a Git repository
  4. Diff between #2 and #1
  5. Diff between #3 and #1
  6. Automatic snapshot after closing GitQlient

In Deleaker you can see the diff between two snapshots by clicking on the Compare with… button. That let’s you select the snapshot you want to compare with.

That’s a nice feature but I was confused since I expected to see the subtraction between both snapshots. What it seems not to be the case at least as straight-forward as I thought for the Snapshot #4.

I compared the status after I closed the repository and this time the results where way better. Deleaker actually detected several leaks I was having!

Leaks found!

One of them was located in GitRepoLoader class: I just forgot to use smart pointers!

Stack trace of Deleaker
Stack trace of Deleaker
The leak is detected!
The leak is detected!

Deleaker also help me finding a really nasty bug/leak that was quite challenge to fix. It involved threads and singletons and it was hard since it was during tearing down the app. The problem is apparently that the deleteLater() was not being called (or maybe not detected by Deleaker, since it’s managed by Qt). Digging more I found that QLogger had an issue when tearing down and sometimes I was actually leaking, so I did a refactor on it.

Another leak was in IssueDetailedView. According to Deleaker it was leaking all around and that was weird:

Leaking that much?
Leaking that much?

This was a especially difficult case to find the leak since the stack trace shows the creation of the object but nothing else. After digging a bit where this class is used I found that I was deleting layouts but not their content:

Forgot to delete those widgets!
Forgot to delete those widgets!

Checking the RAM usage

Another tool that I wanted to use is the RAM analyzer to see how much memory GitQlient is using and if it’s freeing it. I’m not entering in detail about how Qt works and what I can do for that (probably needs a post or a series of them). For the Deleaker review is to see how it performs compared to the Visual Studio tool.

For this case unfortunately I have to say that Visual Studio provides a better integration feature. On Deleaker I missed a mark in the RAM history for when I took the snapshot and to be able to scroll no it’s usage. On Visual Studio I’m able to tooltip the amount of memory that GitQlient was using in a specific moment:

The RAM usage of GitQlient
The RAM usage of GitQlient

Finally, one thing that needs improvements is the over-watch of the RAM when it’s being freed. On Deleaker I didn’t manage to get any significant change in the graph and that difficult me this specific task:

Comparison between Visual Studio and Deleaker
Comparison between Visual Studio and Deleaker

Deleaker review: some final thoughts

I feel that the Deleaker brings a more powerful UI that the tool that Visual Studio uses for the stack trace. It also detects (or at least shows) the files and lines way better and it allows you to select the module you want to process, so you can discard false positives really quick.

The integration with Qt applications makes it way more intuitive and easier to use that the Visual Studio tool. Especially when it comes to identify the file and line that is the root cause of the leak. On Visual Studio that gets quite messy when it comes to show the allocations.

In the performance part, I would like to see some more UI interactions with the RAM graph, especially when linked with snapshots. This can is a very powerful tool if you want to check not only leaks but performance.

New release of GitQlient 1.2.0

I’m happy to announce the release of GitQlient 1.2.0

Three months after the last minor release I present a new GitQlient 1.2.0 with some fixes, several improvements and a lot of new features. For this release I’ve put the main focus in the UI/UX. That includes both the new features and the improvements of the existing ones.

During this development phase, part of the UI changes have happened in the diff widget by providing multiple views for the changes. I’ve also added a tiny text editor with syntax highlight (for C/C++ for now). Other UI/UX changes are the possibility to minimize the branches widget and to pin repositories. All of this has been marinated with an improvement in the way the settings are stored.

Finally, it is worth to mention the tech preview of GitHub/GitLab integration where you can create issues, pull/merge requests as well as see the status of those in the graph view. This is a new path that I’ll explore in the future where I have other ideas about the integration of third party apps. As a complement, from now on, GitQlient will notify you when a new version is available!

The binaries

You can find the binaries for GitQlient 1.2.0 on the release section on the GitHub repo:

What’s new in GitQlient 1.2.0?

The new version includes a lot of things:

  • Pinned tabs
  • GitHub integration (tech preview)
  • Tiny text editor
  • New diff for the WIP
  • Minimalist branches widget
  • Refactored the diff view
  • Bright colours schema
  • Update notifications
  • Settings per repository
  • More configuration options

New WIP diff view

The new diff view adds the possibility of viewing the file in differnt ways (full view or split) as well as navigate through the changes (in the split mode for now).

When the diff it’s opened from the WIP view, it also adds several extra controls like edit, stage and revert.

New WIP diff view
GitQlient – New WIP diff view

New tiny text editor

The second big feature is the tiny text editor I’ve embedded in GitQlient. It allows you to edit the files that are currently in WIP and pending to be commited.

Some times I’ve missed the ability to edit the files because I forgot something and in QtCreator may be I’ve changed the project or closed the file. I usually work with very large projects and it’s very handy to have an editor just in case.

GitQlient tiny text editor
GitQlient – Tiny text editor

The future

For the next release there are some nice features already planned:

  • Add subtree Git feature support
  • Git LFS
  • RPM and DEB packages
  • Prepare GitQlient for translations

As I said, you can see the release planning and all the features that every release will contain in the Release Plan.

As always, if you’d like some feature or you’re missing something in GitQlient, check that it’s not yet in the backlog and open an issue on GitHub!

New GitQlient v1.1.1 (+ Mac)

There is available a patch for the version 1.1 of GitQlient.

The new patch version solves a problem with new repositories. The problem prevented users to work with repositories that have no commits. That applies to both new repositories (via init new repo) and already created repos that don’t have any commits.

I took advantage of this issue to release also a release for OSX. It’s as functional as I would expect to have it in the next 1.2.0. However, I’d like if people can test it before going into the next release.

The binaries

You can find the binaries for GitQlient v1.1.1 on the release section on the GitHub repo:

New GitQlient release v1.1.0

I’m happy to announce the release of GitQlient 1.1.0

After two and a half months from the first release here I present a new release with some fixes, several improvements and new features. The main focus on this release was to improve the stability of GitQlient, making it faster on Windows (there is room for improvement still) and adding some big features that didn’t go into the first release for time reasons.

During this development phase, some non-development tasks where done as well. One thing I wanted was to improve the documentation and the guides and for that reason I’ve shipped the GitQlient User Manual. Another thing I’ve added is Doxygen documentation to the headers (although it’s not yet finished). It will speed up the future documentation for developers who want to collaborate with the project. Related with that, I’ve also set up a Wiki to show the release plan and I’m currently working with GitHub kanban boards.

Finally, in the part of new features, the major addition is The Merge View, that will show the files that are in conflict and will allow you to resolve the conflict. The edition of the files, though, is done in a external editor that you can now configure. The future will be a live editor in GitQlient.

The binaries

You can find the binaries for GitQlient 1.1.0 on the release section on the GitHub repo:

What’s new in GitQlient 1.1.0?

The new version includes a lot of things:

  • New merge view
  • Basic Git config UI
  • Quick access to the recent projects in the init screen
  • Improved display of branches distance
  • Improved UX when pushing a local branch
  • Improved UX when checkout a branch
  • Improved UX for the graph view
  • Ability to open an external editor to edit files
  • Improved performance on Windows
  • Added Doxygen
  • Added User Manual
  • Added Planning

The Merge View

The merge view it’s special since it isn’t accessible as a regular view. It’s only triggered when GitQlient detects that a merge, pull or cherry-pick has conflicts.

GitQlient – The Merge View

As you can see, once this view is activated a red banner will appear under the quick access buttons. It will remain there until the merge is done. It doesn’t mean you cannot do other Git actions. But you won’t be able to push anything until solved. Of course, you can still navigate between all the other views.

The future

As I said, you can see the release planning and all the features that every release will contain in the Release Plan.

As always, if you’d like some feature or you’re missing something in GitQlient, check that it’s not yet in the backlog and open an issue on GitHub!

GitQlient: Multi-platform Git client written with Qt

I’m happy to announce the release of GitQlient 1.0.0

Almost 5 months ago I started this project with the idea of taking an old app and re-factor it. The main focus was to change the the look & feel and creating a Qt Creator plugin based on it. But the most important thing was to have a client I’d feel comfortable to work with.

During the first two months I focused in the separation of the UI and the logic to set a nicer MVC pattern so I could start from there. After that, I started to add new features and removed all the old widgets and functionality that I didn’t need.

For the version 1.0.0 I’ve implemented all the features that were part of GitQlientPlugin with some fixes and improvements. A way more that I initially thought. I’ve been using GitQlient for the last two weeks in my day-to-day work and I feel it’s ready for this first version!

The binaries

You can find the binaries for GitQlient 1.0.0 on the release section on the GitHub repo:

What’s new in GitQlient 1.0.0?

You can find everything that is in the plugin, specially this major ones:

  • Multi-repository support
  • Submodules
  • Tags and stashes
  • Blame & History
  • QLogger as log system
  • New graphic tree representation
  • Improved Diff view
GitQlient showing its main window
GitQlient showing its main window
GitQlient showing the new diff window
GitQlient showing the new diff window
GitQlient Blame&History view
GitQlient Blame&History view

Future

After this release, I’ll start working on the version 2.0.0 and the plan is to have it in 3-6 months. After that I’ll plan how often I want to release major versions: whether 3, 6 or 12 months period.

For the next version the plan is to include the following features:

  • Merge: Full merge support
  • Configuration: Provide UI for Git config file per project
  • Commit additions:
    • Stage changes by hunk and by line
    • Squash commits
  • Diff features:
    • Provide UI for file vs file diff
    • Browse file diff and full commit diff
  • UI: Stylesheet for bright colours
  • More platforms: GitQlient for MacOSX (planned for 2.0.0 if requested)

As always, if you’d like some feature or you’re missing something in GitQlient, check that it’s not yet in the backlog and open an issue on GitHub!

New UI Git plugin for QtCreator: GitQlient

Today I’m really happy to announce that the first version of the Git plugin for QtCreator has been released!

In the last post I advanced some of the final work that will be part of the first version of GitQlient. But what I didn’t explain so far is that that refactor, the re-work and addition of new functionality and the new redesign of the UI had one purpose: provide a Git plugin UI-based for QtCreator!

How to install the Git plugin

You can find the plugin in the release section of GitHub, but I give you the link as well:

Once you have downloaded the plugin, copy it into the QtCreator folder where Qt is installed (Qt/Tools/QtCreator/lib/qtcreator/plugins) or in the following folders:

  • Linux:
    • ~/.local/share/data/QtProject/qtcreator/plugin/<version>
  • Windows
    • %LOCALAPPDATA%\QtProject\qtcreator\plugins\<version>
  • OSX
    • ~/Library/Application Support/QtProject/Qt Creator/plugins/<version>

You need to replace <version> with the QtCreator version (e.g. 4.10.2).

The plugin is activated by default once you have copied it, so you just will need to reboot QtCreator.

How to use the Git plugin for QtCreator

As said before, the plugin will be active by default. That will add a new tab in the left panel with the name of GitQlient (the shourtcut is managed by QtCreator and is Ctrl+4):

New tab option for GitQlient
New tab option for GitQlient

If you go in that tab you will find the main window of GitQlient as it is in the app. I’ve disabled the logs in the plugin but apart from that is the same version.

As you can see, I’ve even added the support for multiple repositories in the view:

Support for multi-repo view - GitQlientPlugin - Git plugin for QtCreator
Support for multi-repo view – GitQlientPlugin – Git plugin for QtCreator

In the top of the window you will find the main controls. You will find all the available options in context menu inside every view. The Blame&History view is also available:

Blame&History view - GiQlientPlugin - Git plugin for QtCreator
Blame&History view – GiQlientPlugin – Git plugin for QtCreator

How to report an error, bug or request a new feature

If you find an error or a bug, please contact me as soon as possible so I can fix it. I’m using GitHub issues to help me on that task.

Since the 99% of the code belongs to GitQlient, please open an issue in that repo on GitHub and I’ll manage from there 🙂

In the Project area, you can see all the new features that are planned for the version 2.0.0. If you want something that is not there, don’t hesitate to add a new issue as Feature or Improvement in the issues page as you did for bug/errors.

Further work

The plan is to release a version of the plugin every time that QtCreator updates.

In addition and not to loose all the new features, I’ll release a new version of the plugin every time that GitQlient updates.

GitQlient: Preparing the first version

In the last post I showed all the major widgets that forms GitQlient, at least in their original design. After a month and a half of intense work, I’ve made some significant changes in the UI but also in the functionality.

For the first version I wanted to improve the UI and make GitQlient as stable as possible. However, I couldn’t resist to add all the features that I was missing for my day to day work. So after this time GitQlient no only had the functionality I showed so far. Here is what it’s new and will be part of the version 1.0.0.

The next post: about the release and something else!

(more…)

GitQlient: The new UI (Part II)

In the previous entry of this series of posts I introduced the change I planned to transform QGit in a new app and plugin called GitQlient.

A new UI for GitQlient

In the old QGit there was a mix of UI files, in place widgets and classes that handle data and return widgets because… why not? A mess. For GitQlient, I separated the UI by scopes and I changed the main window for a QWidget so I can easily integrate it in QtCreator as a plugin.

Centralized controls

In QGit there were a lot of controls, menu and options all around. You could easily feel a bit lost not because of the amount but because of their unspecific behavior. In GitQlient, I’ve opted for a central controls widget, with the main used actions and some additional features but trying to avoid as much as a possible to overwhelm the user. The Controls is widget composed by a series of buttons. The widget allows you to apply the main Git actions but also to move between the different views.

Controls widget of GitQlient
Controls widget of GitQlient
(more…)

GitQlient: The evolution of QGit (Part I)

Update: I’ve been noticed that Heimdal is already used so I’ve changed the name to GitQlient, that is not fancy but it will do it for now! 🙂

Some time ago I started looking into which possibilities I have to handle Git repositories in UI-based. The one that I like the most is GitKraken but I’m not willing to pay the price it cost. Specially since I need to work with private and/or company-hosted repositories. For that reason, I started by looking for a Qt app already made I could use. Or in the worst case adapt to my own use.

I discovered an app called QGit that is available for Linux which I could easily work with. The drawbacks were that it was using really old code and was done in quite an ugly style. Those were two of the most important inconveniences since it I wanted to understand exactly how things were done. And if needed, easily modify the app for my personal needs. After some analysis I came to the conclusion that QGit needs a big refactor. And that is what I’ve done!

(more…)