> If it's so hard to learn about this tool and so easy to learn about it the wrong way, that's a pretty obvious hint that there's something wrong with the tool.

Not necessarily. This may mean (and I think in this case, it does) that people are too afraid to learn about those "internals" - or should I say, the mental model behind the tool (and then some of those people write tutorials for others, perpetuating the problem). And with a "monkey see, monkey do" approach, people can fail at anything, up to and including tying their own shoelaces.

There is no such thing as a perfect encapsulation. Not in programming, and especially not in the physical world. "Internals" are ever-present and leak into view all the time. A good abstraction is just one that you can use day-to-day without constantly minding what's going on behind the scenes.

More importantly though, when you're just learning a bunch of git commands in isolation ("monkey see, monkey do"), you're not learning a tool/an abstraction - you're just learning its interface. That's sometimes OK, but in general, for effective use of an abstraction it's better to learn what moving pieces it is abstracting away. Which in case of Git is that it's a DAG. DAGs are kind of fundamental in programming, too; it's good to understand them.

Its part of a bigger issue - source control tools have wildly different fundamental models. Moving to git from anything else will be confusing, because users jump to conclusion about what commands and operations are doing. Its different from other tools in important ways.

I moved from SCCS to RCS to CVS to Subversion to Git.

Moving to Git was the more difficult step for me. I prefer it now. For a while I had to move back to Subversion and I hated it.

Can't use svn for the life of me, though I used it for 10 years before trying git for a real dvcs need (remote team for a while)...

Just the idea pains me. Missing git add -p, cherry-pick & rebase -i so much I immediately put git-svn on if I have to go back...

Also, it makes telecommuting easier, asynchronous team work so much simpler...

I think the key 'abstraction' that people don't understand is cherry-pick. I can't explain clearly in fine details /how/ it works, but it is the base of so much of git's power...

Monkey see, monkey do would be watching someone use git and imitating them. Reading the manual or an overview of the commands and using them is how learning new tools typically works.

It should be possible to learn the commands for creating a branch, uploading our changes or making a commit like it was/is possible for all version control tools and then move on with our professional lives, which likely revolve around writing software and not fumbling with git.

By the way, I love your conversation about Merkle trees below; it was one of the most surreal things I've read lately. :-)

> It should be possible to learn the commands for creating a branch, uploading our changes or making a commit like it was/is possible for all version control tools

The problem revolves around the fact that, despite same name being used, git!branch != svn!branch, git!commit != svn!commit, etc. They serve related purposes - but not the same, because the concepts behind them are different. Learning a tool means learning those concepts. So in the process of learning "git commit" and "git branch", you're supposed to pick up on the "pointer to a node in a DAG" thing - otherwise you haven't learned "git commit", you've learned something else that's vaguely similar. And then you'll have difficulties when its behavior goes against your expectations.

But they behave pretty darn close to SVN branches and commits and... they're also called branches and commits. It's clear why that happened - no one would have used a weird tool which turned the old concepts on their heads, so git was being taught based on comparisons with existing tools.

Now that git's very popular, the teachers have become arrogant and are claiming that our mental models for how VCS work are wrong and we should instead adapt our thinking to the git internals. In almost all other professions a confusing tool is scorned, but only developers are expected to learn how all sorts of weird contraptions work and then anyone who can't keep up is scorned instead.

git is almost 15 years old and here we have yet another attempt at clarifying how it works to the masses. Why are there so many git GUIs and tutorials and attempts to clarify how this tool works? It's a freaking VCS, not rocket science. git took something that used to be straightforward and doable by any developer and turned it into an over-complicated mess.

Now here's a question for you: why do you defend this anti-developer tool instead of siding with fellow developers?

> There is no such thing as a perfect encapsulation.

It's a logical fallacy to use this as an excuse for a tool having bad encapsulation/abstraction.

Yes it's impossible to have a perfect abstraction. No that doesn't mean we shouldn't try harder.

Completely agree.

> Which in case of Git is that it's a DAG

And one step beyond that, that it's a Merkel tree. It's key to understanding stuff like "if I change a commit, it changes all commit after that" or "if I move (cherry pick, rebase) this commit, I'm creating a new one, not really moving".

> And one step beyond that, that it's a Merkel tree.

Not really, not every block chain is a Merkle tree. Since Git history is not linear, you can’t order the commits in any canonical way. You definitely can order them in some way (like "git log" does) and then construct a tree for that list of hashes, but this is not really useful computation. Git repo integrity is verified simply by HEAD commit hash because you normally clone the entire repository anyway.

Is git even a Merkle tree? Git history forms a DAG, not a tree. But I'm not 100% sure about how the hashes are computed - whether they work on the DAG, or on some local subtree.

No, it’s not. Commit hashes are exactly what it says on the tin: hash sums of commit objects, which are basically text files that include hash sums of tree objects (directory tree state), hash sums of parent commits, your commit message and other metadata. You can see it with "git cat-file":

    $ git cat-file -p d8defd0bb0062ed541de173a2aec834b64d6adbe
    tree cbdb56fe9bb1766d8fc2b2e53c9c934efbacbf1c
    parent a8a1049c06d100a3f926a82414e6addb9b9af5e8
    author ilammy <[email protected]> 1581533224 +0200
    committer ilammy <[email protected]> 1581533224 +0200
    
    fixup! Avoid unsigned overflow in length computations

And compute the commit hash manually to verify that:

    $ sha=d8defd0bb0062ed541de173a2aec834b64d6adbe
    $ cat <(echo -ne "$(git cat-file -t $sha) $(git cat-file -s $sha)\0") \
          <(git cat-file -p $sha) | sha1sum
    d8defd0bb0062ed541de173a2aec834b64d6adbe  -

Git prefixes object content with object type ("commit" in case of commits), its size in bytes (textual, decimal), terminated by a null byte. And hashes all of that get the commit hash.

>that's a pretty obvious hint that there's something wrong with the tool.

Or that the problem space is inherently difficult.

Almost everybody I've ever worked with who complained about Git has a conversation with a coworker that goes something like this:

Coworker: "I really hate Git, it's so hard to understand what's going on internally."

Git guy: "Did you read the documentation?"

Coworker: "Nope."

Git guy: "Did you read Git - book?"

Coworker: "Nope."

Git guy: "Did you read Scott Chacon's 'Pro Git'?"

Coworker: "Nope."

Git guy: "..."

That conversation already went off the tracks at "internally", since it shouldn't matter at all how it works internally. We do not learn how most things work in detail, because we wouldn't have time to live our life if we did.

In this particular case, git is a version control tool and it supports various typical operations for such tools. One should be able to learn the commands and then successfully use the tool. If that's not possible, I continue to assert that there's a problem with the tool.

The likelihood for this conversation to occur, in a way, also depends on the tool itself, and tells us something about it.

As a matter of fact, git is hard to use.

The question is: keeping the same level of functionality, could it have been made easy to use?

It also speaks about the quality of users as a whole - we somehow forgot to RTFM at all or lead people to documentations, simultaneously accepting lack of documentation in a vicious cycle.

And the answer is: yes, absolutely. Mercurial is a whole level better. Unfortunately git won - because of GitHub, not on technical merit.