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.
You can find the binaries for GitQlient v1.1.1 on the release section on the GitHub repo:
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.
You can find the binaries for GitQlient 1.1.0 on the release section on the GitHub repo:
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 User Manual
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.
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.
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!
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!
You can find the binaries for GitQlient 1.0.0 on the release section on the GitHub repo:
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!
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):
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:
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:
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.
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!
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.
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.
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!