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

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?

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

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.

This entry was posted in programming. Bookmark the permalink.



3 Responses to Getting Git

  1. Jeff Benson Mozilla Firefox Windows says:

    So anyone who expresses an opinion about the quality of Git’s interface isn’t a real software developer? Git is powerful, and I use it every day, but it is also one of the highest learning curves among current version control tools. When using it on Windows, it leaks a lot of Unix-y stuff (especially if you have to use Git Bash to accomplish certain things). There are some who find heavy dependence on the command-line to be clunky and inelegant, myself included. Your elitism won’t make anyone love the tool more!

    Reply  |  Quote
  2. Luke Maciak UNITED STATES Google Chrome Linux Terminalist says:

    Jeff Benson wrote:

    So anyone who expresses an opinion about the quality of Git’s interface isn’t a real software developer?

    Yes, that’s exactly what I said in the last few paragraphs as I discussed a lot of gits shortcomings and actual flaws in the UI. TLDR: git isn’t perfect, but complaining that it’s command line or uses unix tools is silly considering what it is, and what it was designed for (ie. Linux Kernel source control).

    Jeff Benson wrote:

    Git is powerful, and I use it every day, but it is also one of the highest learning curves among current version control tools.

    Right. Same can be said for Vim and Emacs both of which are fantastically powerful tools with very steep learning curves. My point is that sometimes complexity can’t be simplified and abstracted down. Yes, there are source control tools that are much easier to use but they are not as popular, and don’t offer as much flexibility as git. Sometimes putting up with the learning curve is worth it.

    Besides, Git is an open source project which means as users we can help to improve it by submitting enhancement requests, patches and writing better documentation, tutorials and etc.

    Jeff Benson wrote:

    When using it on Windows, it leaks a lot of Unix-y stuff (especially if you have to use Git Bash to accomplish certain things).

    Right… I don’t see the problem here. I mean, I’m trying to see your point, but it is escaping me. Here is the thing: there are currently two relevant desktop operating systems on the market: windows and POSIX-compatible unix-like systems (linux, unix, osx, etc..). Some environments are built for Windows, others work better under unix-like stack. When you start a project, you pick the right environment for the job. Most competent programmers are not one-trick ponies, but are capable of working in a variety of environments and stacks. So they should be comfortable jumping from one OS to the other if a project requires it.

    And I’m not talking about dual booting or anything barbaric like that – it’s 2013, not 1991. Nowadays you just slap a pre-made VM onto your hard drive and type in “vagrant up” or something like that. Seriously, few days ago I walked a totally green intern through creating a fully functional LAMP environment on his Win7 laptop using Vagrant and it took us like 15 minutes going from 0 to phpinfo test page. If someone can’t do it, I don’t want them touching any code.

    If you are profoundly uncomfortable using bash, this tells me that:

    1) You never worked on a project that involved a linux/unix server
    2) You are not inquisitive enough to even play around with the ONE other major OS out there to get a feel for it.

    Both of these things are pretty bad in my book.

    Jeff Benson wrote:

    There are some who find heavy dependence on the command-line to be clunky and inelegant

    I… I’m sorry, but I can’t relate to that. I think that command line is just about the most elegant thing you can get. You have commands that use STDIN and STDOUT and you can pipe stuff between them creating complex chains out of simple components. You can save these commands into a text file, and all of a sudden you have automation. There is a built in command history that provides you with a searchable audit trail. I can use the script command to save my entire session into a text file. I can use tmux, start a big compile or batch job, detach the session, drive home, ssh to my work computer, attach the session and check the progress of the job.

    I actually get annoyed when things don’t have scriptable command line interfaces and force me to context switch, grab the mouse and push buttons like it’s a Zynga game or something.

    Reply  |  Quote
  3. Jeff Benson Mozilla Firefox Windows says:

    Thanks for the response. I’m not “profoundly uncomfortable using bash,” but I don’t want to use it on Windows because it’s not Windows-y and practically no other respectable tool claiming good Windows support requires me to. Luckily I found PoshGit for PowerShell, so now I can do Git-related things in the same style and with the same mechanics as I do anything else on my Windows 7 system.

    I understand the power of piping and composition that is available from a good shell environment, but as a visual person I appreciate tools that can transcend these mechanics and provide a reasonably good visual representation that’s a little closer to most people’s mental models of what they’re doing at a higher level. I respect your preferences, but I do still appreciate when tooling doesn’t lean so heavily on making users – even power users – work with a command line interface for day-to-day stuff.

    Reply  |  Quote

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>