Hacker News Reader

Comment by scrollaway | Hacker News Reader

Git has done a terrific job of it. It just doesn't do a great job at communicating what it does, how it does it, why it does it that way and how to achieve those results.

In other word, git's great internally... externally it just has a poor UI. But what's new there.

View on HN

Every source control system has had a terrible UI. I mean, most of them don't even really make an attempt. (Unless you count things like Time Machine or Microsoft Word's revision tracking, those are both acceptably decent.)

But Git is a whole 'nother layer of awful beyond all of them.

Another one of the "reasons I can't get along with Linux users" is that they see something like Git and just kind of shrug and deal with it instead of getting angry that we have a piece of basically brand new software that was built without even attempting to incorporate any UI concepts we knew about at the time it was written. And since it's a CLI that about a thousand other scripts and tools consume (instead of having proper separation of the human interface from the machine interface), it basically cannot be improved at this point, not without breaking thousands of third-party tools. Sigh.

That's pretty much true of the entire baroque edifice of unix-based CLI tools. They are what they are, and they can't really change much. Its an increasing hill to climb to become proficient, and those already comfortable have no incentive to change it.

Which is awful, because there's nothing stopping usability development in CLI environments (look at Cortana or Siri, for example, or to a lesser extent PowerShell) except that awful stagnation.

People shouldn't have to bend their brain to work with a machine. The machine should be designed to work with human brains.

And to be that snarky person for a second: I've heard a lot of people who actually love Linux CLIs still complaining about Git's weird-ass behaviors. https://stevebennett.me/2012/02/24/10-things-i-hate-about-gi...

I think it's a problem that you don't need to know Git that well to use it productively. Once you get the basic commands you can pretty much put away Git's documentation for a few years until something goes particularly wrong. It's been on my "list" for a long time now to deep dive into it but I've just never had the impetus to do so despite the fact that I use Git every single day.

I think the real problem is that "knowing git that well" is even a thing. If git's interface were more predictable and if its abstractions were less leaky, learning the basic commands would be enough and noone would ever need to do a deep dive into the documentation.

I finally realized this after reading this xkcd comic[1]. Now I'm happily using mercurial (with hg-git) whenever I expect that I will need to do something nontrivial.

https://xkcd.com/1597/

I.. yup. That comic never ceases to amaze me.

I don't completely agree. While git definitely could still be more polished, the problem it tries to solve is fundamentally complicated.

Git does a good job of cleanly modeling the graph of distributed changes and providing a set of useful operations on that graph. The disagreement is more about whether somebody has learned or should learn that underlying graph.

If Git were well-designed, it'd be free of rough edges and "gotchas", and it would teach you how to use it as you used it by making use of discoverability. If Git were a well-engineered piece of software, it wouldn't even have a manual (certainly not a "required reading" manual).

The purpose of software is only partially to solve problems, the rest of the purpose is to serve as a liaison between user space and implementation space. Many tools with bad UI forget about that second part, but human factors are hugely important in the success of software.

Reply on news.ycombinator.com