Git is too hard

In my opinion relying too much on user understanding implementation is a mark of bad design. I don't care about more advanced functionalities of git, on daily basis I have very simple workflow that I want to "just work". Sure I can spend few days studying git internals, but it feels unnecessary. Especially given that in the past I've worked with simpler proprietary tools that "just work" (though did not have equivalent of "power" features).

On the other hand I think git is like bash - has some serious warts but it's good enough to be used widely; and unlikely to be replaced by anything else at this point.

I like to say that git is a "white box". You need to understand the internals to be able to use it.

Contrast this with "black boxes" where you don't have to or even can't understand what's going on.

Some would argue that software shouldn't be built that way, but I will respectfully disagree. It's not an end user facing consumer product, it's a tool for professionals. You wouldn't expect anyone to operate a table saw or a milling machine without some understanding of what's inside the machine.

I do agree that the git user interface is inconsistent and full of caveats. But as long as you understand it's just a directed acyclic graph of commits, you can dig yourself out of any hole you get into.

Once you separate the two skills you get 4 classes of people (with gradations):

1. don't understand it, cannot explain it. 2. do understand it, cannot explain it well. 3. don't understand it well, can explain it well. 4. understand it well, explain it well.

Number 2 are good practitioners and not as good teachers. Number 3 are good teachers but not as good practitioners. Number 4 are good teachers and good practitioners.

Everyone wants to learn from a number 4, but they are more rare then the 3s and 2s. Between a 2 and a 3, you'd rather learn from a 3. If you don't need to learn, you'd probably rather work with a 2 than a 3. Basically, even if their mental model isn't perfect, they deliver explanations that can quickly lead others to at least be as good as them and possibly better quickly if you can see the mistakes in their mental models (their descriptions could potentially be 100% accurate without it reflecting their poor mental model).

Anyways, this observation leads to the standard cliche, "Those that can, do; those that cannot, teach."

Google's perforce with mercurial client has been the best VCS I've ever used and I now have a deep hatred of everything that isn't that system, especially git.

Git's UX, like a famous programming language, was never designed in a strict sense. It's clearly been written to solve immediate requirement, one by one, without a vision (again, from a UX perspective).

Result: the horrible checkout command, which does a zillion different things, and I bet only few users know all of them. Same goes for reset.

I don't remember all the checkout forms, and I couldn't use git without aliases.

The porcelain interface is another one. Excerpt:

  This is my fault, to some degree.
  The "short-status" form is meant for human eyeballs, and was designed by Junio.
  Some people wanted a scriptable status output, too, so I slapped a "--porcelain"
  on the same format that turns off configurable features like relative pathnames
  and colorizing, and makes an implicit promise that we won't make further changes
  to the format.
  The idea was to prevent people from scripting around --short, because it was never
  intended to be stable.
  So yeah, while --porcelain by itself is stable and scriptable, it is perhaps not
  the most friendly to parsers. The "-z --porcelain" format is much more so, and I
  would recommend it to anyone scripting around "git status"