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!
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:
You should consider a new name. Heimdall is a well know opensource software on the Android community: https://gitlab.com/BenjaminDobell/Heimdall
Using the same name clashing will for sure upset some people.
Great job, anyway
Thanks for letting me know that! I really didn’t pay too much attention to the naming.
I’ll have to find a new name, then! 🙂
This looks interesting. For the Kate text editor we recently did some planning and brainstorming, and we want to have a better git client integration in Kate as well, see: https://kate-editor.org/post/2019/2019-09-09-kate-planning/
Maybe we should have a look at this project and find out whether this would be feasible to use in Kate as well?
PS: You should add some screenshots for the Qt Creator integration. Is it embedded in Qt Creator, or a separate “external tool” process?
Ah, and i) do you accept patches, and ii) would you consider relicensing to LGPLv2+ (or even MIT or so)? Since we have the unfortunate situation that in Kate we still have some GPLv2 only files, and currently I’m not sure whether this is compatible to LGPLv3+
You’re welcome to check the code and please let me know if I could help you with Kate, I was a user of it when I started with RedHat and then in Mandriva.
I’ll add some screenshots soon but I can advance you that is embedded IN Qt Creator. I’ve prepared two more posts about GitQlient and one about how it integrates in Qt Creator 🙂
i) Of course I’ll accept patches, the problem is that QGit was just full based on them and they didn’t feet exactly how I work with Git, but I’d be happy to have someone that helps me with that.
ii) I didn’t decided yet on the license but it will be public for sure, taking into account that I took someone else code, and I want to integrate it using Qt in a free way. I just need to check the differences between LGPLv2/GPLv2/LGPLv3+/MIT 🙂
I assume if this is QGit based, you are tied to the license the original code had I assume.
We as the Kate team would appreciate if we could integrate some well working git client, if we can cooperate there, this would be fantastic ;=)
Yes, is QGit based and for that part of the code I’m tied. But I assume even in that case wouldn’t be a problem for Kate, right? The plan is to release as free open source as possible 🙂
About the integration, for the moment is an ongoing project, so may not be full of features.
Let’s keep in touch 😉
I have taken a look a QGit, seems to be GPLv2.
That would be compatible.
But if you don’t want to end in the same bad situation as us (parts is GPLv2), perhaps you could ask the original author if some less restricted license would be ok for him.
GPLv2 only is really a bad “dead end”.
For the cooperation: Perhaps you can try Kate’s current master version with the project stuff and lsp client, then you get a feeling that we are still missing any real git feature beside simple “collect all files” ;=)