This is a very useful comment.

I think the same could be said about C. It should not be put on the throne of "programming language" - you need to actually read and understand what it does internally. (pointers etc) - it's not enough to learn some incantations.

So then let me ask: is there a room for x, where git:x::C:python (git is to x, as C is to Python).

People everywhere deserve to have x. Not just right-clicking a file in Dropbox or OS X for previous versions, but a full commandline and detailed history including commit messages, and many other aspects of git.

In a way this is completely orthogonal to your comment, just as Python is to C.

EDIT: I've thought more about it and I no longer agree. The "language" presented here is a subset of C/C++ - not everything is mentioned or taught: https://www.arduino.cc/en/Reference/HomePage

It is in fact exactly this type of simplified subset. Not even malloc and free are mentioned... So while what you wrote is true for this audience (HN) there is room to learn less or a subset.

Mercurial. I'm not being flippant; the UX is light years ahead in terms of accessibility to newcomers to dvcs. With a ui like tortoisehg, even five years ago, someone without any prior experience in any vcs at all could become productive after a fifteen minute primer. Git does not compare.

It also makes sense, I think, considering that Git consists of small tools interacting with each other, while Hg is written as a whole application/system by itself, which can then be extended as needed.

Yes, I believe as well there should be an assessible solution and that should be the standard. However in this case there is none, since weirdly enough git is sitting on the throne. You can try to establish other tools like mercurial in some projects, but you may end up getting harsh resistance by exactly the people you try to serve with that option.

> "But I disagree with that it would be an acceptable goal in git just to understand a subset of it. You need to understand nearly everything, even the internals. Only then it can really become useful to you."

Sorry, but this is patently false. I've been using git very effectively for years, both as a participant and as a repo admin, have had other Senior Developers call me a "git hacker" and ask me for git help, and I have no idea how the internals of git work. I also use a very small subset of git functionality, and many of the commands in the OP look like greek to me.

I don't doubt that your approach is one way to learn/use git. But learning git as a black box, and using just the parts you need, is perfectly useful as well.

Potentially dumb question here, but couldn't 'dragging out the inevitable' be another way of phrasing 'the learning process'? It seems that immediately making a tool usable would be preferable to keeping it as a purely theoretical device until it's fully learned.

If you are this kind of person who is interested to learn, but has no problem with using stuff despite it being a little rough in the beginning, then yes you are more than welcome. In fact I would say that is how people learn. You cannot just read a book. You also need to use it.

But that is not how most beginners approach tools. For most people a tool should serve a purpose and do that immediately from the get go. And for them git is really painful in the beginning. And if they don't put in the learning effort it will still be that annoying a few years down the road.

That's what I meant. Thanks for letting us clarify that together.