Git GUIs: A Tale of Two Source Models
I’ll confess: I use a GUI for Git. Not always, and not even most of the time. The CLI is usually quicker, and I’m usually in the terminal anyway, but yet I also use a GUI. Why? Primarily for reviewing diffs and history, or for performing rarely used operations. I mean, I can google “cherry pick” for those rare times I use it, or I can choose it from the menu and not worry about mangling things in Git history.
I’m a long-time user of Tower on macOS. It’s beautiful, intuitive, feature-rich, and powerful. Updates come frequently, and they even have cool merch. I have this hanging by my desk at the office I haven’t seen since mid-March. I assume it’s still there. They also offer Tower for Windows. What they don’t have, however, is a Linux version (preemptive snark: “That’s because people who use Linux don’t use GUIs!”).
Closed Source: GitKraken
I asked Slant what Linux Git GUI was best, sifted through some editor plugins and “minimal” clients, and decided to try GitKraken. I’d tried GitKraken on macOS years ago, and thought it had promise. Back then, though, I’d already cast my lot (and my money) with Tower, so I never dug into GitKraken. Now, it was time.
I installed GitKraken and began using it. It ticked all the boxes for me: intuitive, beautiful, and feature-rich. After a few days using it, I decided to show my support by purchasing a license (preemptive snark: “People who use Linux don’t pay for software!”). GitKraken offers three flavors:
- Free (“For open source developers”)
- Individual (“For individual developers” — $29/year)
- Pro (“For teams and companies” — $49/year)
See more information on their page. Among other things, Individual lets you access private repositories. Pro adds enterprise features: user management, GitHub Enterprise, etc. The tiers and features make sense. It’s a reasonable approach. Since I have no enterprise needs, but I do want to work with private repositories, I paid $29 for an Individual license. And I continued to use GitKraken.
After some days or weeks of use, I decided to really dig into GitKraken’s settings and understand its suite of offerings. I found the Preferences screens, and saw I could configure an External Editor and a Default Terminal. When I tried to select a different editor, I saw that my only option was “<None>”:
I poked around a little bit in the UI, ran a few google searches, and came up empty on how to resolve this. I saw a menu item in GitKraken, though, that said, “Send Us Feedback,” so I sent the following:
I’m using GitKraken 7.0 on Pop!_os 20.04. In Preferences -> General, both the External Editor and Default Terminal dropdowns have <None> as the only option. How can I configure these?
The reply came back:
Thank you for taking the time to reach out to support. We currently do not provide support for free accounts. For guaranteed support please upgrade to GitKraken Pro. Additionally, it’s important to note that the GitKraken Git GUI does not support Pop!_OS. Our team does not test again this distro and we cannot guarantee that the GitKraken Git GUI will behave properly. If you have installed the GUI via snap please try one of the alternative install options detailed here, https://support.gitkraken.com/how-to-install/#linux-deb-rpm-and-targz-files. If you require additional assistance please upgrade to GitKraken Pro.
I assumed a mistake had occurred — true, I didn’t have a Pro account, but nor was I using a Free account. I started to reply that I wasn’t a Free user, but first I checked the features of the different pricing tiers. Indeed, they provide email support only for the Pro edition. A customer paying at the Individual level has no support recourse. The support individual hadn’t made a mistake (other than getting my license wrong) — he had followed protocol. Now, I felt a little miffed. Dismissed. At the least, they could have said something like: “Thanks for pointing this out. We are developing a support document that addresses where this information comes from to help you troubleshoot,” or something that sounded like they cared. Still, I hadn’t done my homework when I made my purchase. The terms were right there. I should have paid more attention.
I briefly considered throwing them $20 more just so they’d have to fix this for me, but realized they’d almost certainly stand firm on not supporting Pop!_OS. So I reformatted my hard drive and installed Ubuntu . . . just kidding. I kept my $20. And I tried to solve this myself. Things I tried:
- Find the configuration file: check
- Add good-guess entries to the configuration file: didn’t work
- Install VS Code to see if it it would show up in the dropdown: didn’t work
- Install and configure GitKraken on my MacBook Pro with an External Editor and see what the configuration file should really look like: check
- Duplicate the configuration file on my Linux box: didn’t work
At this point, I ran out of steam. GitKraken is an Electron app, if I’m not mistaken, so I suppose I could have tried digging into obfuscated JavaScript. I’ve seen what WebPack can do, though, and I also figured the license I’d agreed to prevented such action, so I surrendered and looked for another Git GUI.
Open Source: Guitar
I don’t remember how I found Guitar — I assumed Slant, but I don’t see it now on the list so must have been a random Internet search that led me to it. I installed it, used it, and liked it. Not quite as intuitive or beautiful as GitKraken, but I soon got the hang of it and I was off and running.
One day, though, I wanted to amend a commit. In Tower, the commit dialog has a checkbox for amending a commit. Guitar has no such checkbox. I poked around a little, then dashed to the command line to amend the commit and made a mental note to follow up.
When I got around to following up, I found this issue asking for an option to amend a commit. The response from the developer pointed out that the option existed, albeit using a different interface mechanism: a context menu. I right-clicked one of my commits in the Guitar GUI and didn’t see the “Edit message…” option. I didn’t understand why. This time, though, I could do something about it.
I cloned the Guitar repository, fired up Qt Creator, followed the build instructions, and was able to launch Guitar in the debugger. I looked through the code, which was clean and straightforward. Easy to follow — and this, for a guy who only recently learned that Qt is pronounced “cute.” (Note: I find that pronunciation more unsettling than Jay-Double-you-Tee being pronounced “jot,” but no one consulted me on either.)
I soon found the part of the code that draws the context menu in question, set a breakpoint, and stepped through the code. I learned that it adds that menu item to the context menu of a commit if:
- It’s the latest commit
- There are no uncommitted changes in the working copy
- The commit has not been pushed to a remote
So the feature works as the developer designed: you can edit the message, but not the content, of the commit. In other words, you can’t add a file to a commit to amend it. And I could figure all that out because the code was open source. I could see it. Step through it. Know exactly what was happening. And I can change that behavior, if I want, and offer it to others who want the same behavior.
Conclusion
Here’s where I say that Open Source is categorically better than Closed Source. I can’t do it, though. It’s not categorically better. It’s better in some ways and worse in others. It optimizes some things at the expense of others. It worked in my favor, above, allowing me to troubleshoot and resolve my own issue.
As commercial software, however, GitKraken generates sufficient revenue to have (presumably) developers, designers, product owners, and support staff working on it full time. It’s more intuitive and better looking than Guitar. It offers ticket tracking boards and project timelines and integration with other tools. And as long as you pay $49/year and run a supported operating system, you can get email support for it. In contrast, I’m guessing that Guitar is a side project for its developer. They get no money from it. It puts no food on the table. They work on it as they have time. And I keep saying “they” because English has no genderless singular third-person pronoun, but you can see soramimi does most of the work. It’s a labor of love, and a gift to the community.
This is where the pedant points out that you don’t have to be closed source to be commercial. That’s true only in theory, as the recent hapi flap reminds us.
Life is full of trade-offs. Software is one of them. I’ll go on using some closed source and some open source, paying for some software and using some for free. I’m going to thank the developer of Guitar for all their work. I’ll be writing a patch for Guitar that allows you to amend a commit by adding a file. I’ll check it in using a Git GUI. I’ll let you guess which one.