Getting Git

If you visit the internet sometimes, you have probably noticed that every month or so certain “developers” like to have a crying session about git being hard to get. I use the term developers in quotes because it is probably too generous to give them this title. More apt job title would probably be “program code entry specialists”. You know, folks who treat software development as a 9-5 job which they mostly hate. These guys tend to be really vocal about things like user experience.

That is by the way, the typical theme of their regular “bawww-fest” over git: the user “experience is shitty” they say. I never really understood this because to me the tool is pretty transparent. Granted, when you try to do something complex (and by complex I mean in terms of maintaining project integrity and history – not what your brain stupidly deems to be conceptually trivial) it can be somewhat tricky. But your regular, day to day interactions are absolutely straightforward. In fact, much like Google, when you make a typo, git will try to guess what you meant:

Git is Helpful

Seriously, what is wrong with this user experience? It has informative command prompts, easy to remember commands (well, for the most part) and good error handling. It is actually very difficult to fuck up your repository in a way that can’t be easily reversed or fixed, and it helps you out at each step. What exactly is the problem here?

What is the big issue most people seem to have with git? It’s that you have to use the command line sometimes:

I have to use command line?

No, seriously there are people out there who will claim that CLI == bad UX with a straight face. Or if their face is not straight, they will try to make it into a joke along the lines of The 80’s have called and they want their command prompt back. Or something equally silly. There is astonishing number of people in our industry who straight up think that CLI is something bad, antiquated and generally useless. After all, if it doesn’t have buttons and sliders, it is not worth using, right?

GUIs are appropriate for just about everything, right? Any and any command line utility can be made 100% better with a GUI, right? You just can’t go wrong adding a GUI to some simple CLI app, right? Like, for example, if I’m too much of a crybaby to learn to use wildcards to rename my files on the command line I can download this nifty Windows bulk rename utility to make it easier:

Bulk Rename

This GUI sure is intuitive and simple to use guys. It just oozes good user experience, doesn’t it?

I’m being factitious of course, and the above-mentioned example is a bit of a straw-man. It is one of the most terrible examples of UI design out there. Not like I’m so much better than these guys. My Setup Assistant tool also looks like shit covered in colorful buttons, but I mostly made that for myself, so I don’t particularly care. Despite not being particularly well planned or designed tool, it works remarkably well for my purposes.

This is sort of how git was designed – it was something Linus made in order to make management of the Linux kernel easier for himself. This is a bit why it behaves the way it does, the documentation is mostly incomprehensible. It is a tool that works, and that helps thousands of people and companies to contribute to open source projects every day. It is not perfect, but it does the job remarkably well.

The point is that while git has many shortcomings, the fact that it exists on the command line, and heavily leverages the unix stack is not necessarily one of them. It is a function of it’s design.

The other day I saw someone whining that Git requires you to install a MinGW unix shell emulator on Windows in order to run it’s own self-contained mini-bash environment. It kinda surprised me, considering we were talking about a tool written by the creator of Linux of the specific purpose of managing that operating systems source code. I’m sure that someone could implement git to somehow work natively on Windows, but Linux and his team really have no reasons to do so. Especially since the Windows version as it is right now lets you inject the git executables into your path so that it works almost as if it was a native shell app.

If you are really, really, really do not want to learn to git on the command line, you can always use Tortoise Git or maybe GitHub for Windows… But, therein lies the problem. You are refusing to learn something new. Is that wise?

Let me put it this way: when you choose to become software developer, you more or less make a commitment to life long learning process. Our field is one that moves rather fast (not as fast as computer illiterate people think it does, but still fast) and if you don’t make at least a half hearted attempt to stay on top, then you start falling behind. If you don’t know, and refuse to learn Git, you are less valuable as a programmer and that’s the long and short of it.

No one can force you to use git, and you are free to employ another distributed version control tool like Mercurial for example. You will probably notice that while most of these were created long before git, none of them attained its popularity, community support and market share. Does it make git inherently better? I don’t know, but statistically it makes familiarity with it a more valuable skill to have, because you are more likely to encounter it when you go to contribute to a project or are hired to work on one.

Git is not perfect mind you. Like most software, it has many flaws and odd quirks.

For one, its documentation is atrocious. Actually no, I take that back. The docs are actually great at explaining the internal workings of the tool – they are just not targeted at the end user. The language is dense, but very specific and descriptions reveal much about the design goals, expected behavior, exceptional states and special cases. What they do not include are simple, newb friendly instructions. So if you want to learn how to check stuff out of a remote repository, then the official docs won’t be any help. It was written by git developers, for git developers. This would be pretty terrible if it wasn’t for the fact that these days we have the internets at our fingertips and a lot of smart people already wrote amazingly detailed and readable tutorials and manuals that use accessible language and use pictures. Hell, there are even interactive tutorials out there. So saying git is hard because the official docs are indigestible is like saying C++ is hard because Stroustrup’s reference book is long and dense.

The information model of git is much more complex than that of say Subversion which only has a working directory and the repository. Git has the index which acts as a staging area for commits which adds a lot of complexity to the work flow. It is also built from ground up to be fully distributed so a user of git has to also worry about the local and and one or more remote repositories. But once again, all of this architecture is there for a reason. Git was built to allow maintainers of huge projects (such as the Linux kernel) to be able to manage contributions from thousands of submitters with relative ease. This is where git shines and reducing or abstracting this complexity is not an option.

The unfortunate part is that a lot of the complexity tends to leak out into the UI and has to be internalized by the user. If your main problem with git is “leaky abstractions” then you are absolutely in the right. Most git users are forced to learn a good deal about the systems architecture and information model in order to be able to perform some less common, more complex tasks.There are also many inconsistencies in the git command set. Fortunately this has been slowly improving. Proposals and contributions that aim to improve the way git UI works have been slowly trickling into the code base. So this problem is completely solvable – it just requires time and resources.

Fortunately, git has a built-in mechanism for correcting often shitty command syntax. Whenever you find a command that drives you absolutely crazy or is virtually impossible to memorize, you can alias it. Much like shell aliases, git aliases live inside your config file, and are perfectly portable from one system to the other. This means that you are given power to abstract any and all parts of git command language for yourself and only yourself without forcing your particular view of how git should be onto anyone else. So I urge you to make liberal use of this feature, and share your aliases with the world. This will both improve the user experience for others and also help to point out inconsistencies in the command set itself.

Just remember that anything worth learning is not going to be easy to grasp at first. The more powerful the system, the more difficult it is to build a UI that both exposes all the features in a practical way and is user friendly, easy to grasp and intuitive. Almost invariably when you abstraction is reductive: to make something easier, you take away some of power and flexibility from the user. If you still want to expose the internal workings of your system, then users will end up using and relying on these back-doors. Now you have leaky abstractions and inconsistent UI. Getting this balance of easy to use vs powerful and flexible is one of the biggest problems of UI design and what’s worse there is no clear way to solve it.

Git is great, but it also sucks a lot. This is true for every piece of software ever made by man. Perhaps one day post singularity AI’s will bestow upon us clarktech with perfect UI designed to be both completely intuitive and infinitely complex and flexible. But we are not there yet. Right now git is the distributed source control system of choice for majority of open source projects out there, and learning it is definitely not a waste of time. Complaining that it was designed as a CLI application or that it the Windows version ships with a subset of POSIX tools (instead of leveraging powershell for example) is just silly and kinda embarrassing. Pointing out inconsistencies or problems with the UI, and ways these issues can be fixed or abstracted on the other hand is constructive. So do that instead, will you?

It is perfectly ok to hate git because of it’s flaws. Hating it because it’s hard and scary is laughable.