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!

My requirements

We all know that without good requirements at the start, we can end up in an endless project. Before touching any code I wrote what I’d like for my code and which are the musts.

Remember: Is not how your requirements define your code. Is how your code fulfills the requirements.

Here is what I wanted:

• The code following the SOLID principle
• MVC pattern according to Qt
• Self-documented code: documented with doxygen but easily to understand just by reading classes and methods
• Simplified UI: I don’t need to do the most complicated things on Git. I want an easy-to-use application
• Modern code: I want to use some C++17 features or at least be able.
• No warnings: none, never. Warning as errors flag activated
• No deprecation uses
• Simple Git usage: I don’t need to work with patches when I just want to commit
• Integration with Qt Creator

What I’ve removed

The existing code in QGit has some features that for my needs they just add noise. So the changes are:

• I removed all command line arguments support. Since GitQlient is GUI based I don’t need to initialize or pass any arguments. The user will open the repository they want at the beginning or it will be open automatically via QtCreator.
• QGit uses a lot of old and from my POV dangerous code. There are a lot of places with goto and C-style casts. So I’ve replaced a lot of code and split it in several classes by functionality.
• QGit uses an old fashioned architecture: everything is totally tied. It makes impossible to modify or extend (i.e. the inheritance from Domain instead a used-by).
• I’ve removed the crazy event system used as well. It tied the main window to the whole app.
• Since I don’t need the exception system that QGit includes I’ve removed it as well.
• The patch system has been replaced for a commit-based system.
• Since I don’t want patches, all the support for StGIT is unnecessary.
• I’ve removed the support for external tools. I want to provide my own diff tool and file viewer for GitQlient. In addition, I’m designing GitQlient not only as a standalone application. The main use is as plugin for QtCreator. For that reason it doesn’t make sense to use GitQlient just to commit, push and pull. The (Git) terminal is faster for that purpose.
• I felt that QGit had to many options to configure when I just wanted to have it as a plugin.
• QGit also have a lot of UI configuration that needs to be stored. I’ve removed the settings system of QGit since I don’t provide such configuration.
• I’ve removed all the boilerplate related with project files. I just kept the QMake project, for now. I will move it to CMake soon.

What I’ve added

The code has changed a lot and only few classes remain from the original project. I knew that it was going to be in that way and that’s the main reason because I didn’t fork QGit directly. If someone sees it as customization it wouldn’t be true.

• The biggest change (according to number of lines and files affected) is the refactor I’ve applied. I split the functionality in data classes but also in UI classes that didn’t exist before. I want classes with a single responsibility, not a big chuck of code ready to eat.
• Thanks to the previous action, I’ve been able to modify the UI in my own look and feel. I feel that QGit is really messy and hides all its potential. Clear UI files and classes to handle the user input.
• One of the major changes has been removing the main window that was injected everywhere. Qt provides an amazing mechanism called Signals&Slots that makes obsolete the event system the 90% of the time.

Check the differences at the moment: