This is the right way to learn Git. I don't know how good this is, but I feel most of the strange unintuitiveness of git went away and was replaced by a feeling of productivity since I understood what happens under git's hood.
Agreed. Rather than memorizing a set of commands, if you know the layout of a git repository, you start thinking about the state you want to put the repository in and how to reach that state using git commands.
The big take away for me was the idea of blobs and trees as Hickeyian values and commits as Von Neumann places. [1] If there is one weakness is the article it is ending with stash, which to me seems to be a bit of a feature in search of a workflow more than something that enhances distribution and sharing among a team in so far as the class of problem it addresses seems to result from larger issues of team structure and workflow [if it's worth saving then the whole team should know about it and have access].
It's useful to know about, but placing it at the end makes it seem like a high order bit rather than something for a corner case.
I find stash useful primarily as a place to hold things for a few minutes, and no longer. In particular, I frequently use "git stash", followed by "git pull --rebase", and if all went well, "git stash pop". I could just as easily do "git commit -a -m 'WIP'", "git pull --rebase", and "git reset HEAD^", but I find stash more intuitive.
That sort of gets at my point, stash makes sense in a corner of a high disciplined workflow. But the article presents it as approaching "best practice" and as a belt to sport with one's lederhosen. By analogy it's a bit like multiple inheritance in C++, on occasion and for some people it might be just the thing, but it's probably not a good starting assumption at the design phase.
Though again, it's a minor criticism and mostly related to the impression of importance positioning it at the end of the article suggests [i.e. placing the strongest point in paragraph four of the five paragraph essay].
I suppose I was thinking more in terms of idempotency than persistence. N Shakespearean monkeys type:
$> echo "A rose" > any_other_name
$> git init
$> git commit -a -m "Initial Commit"
There's one blob hash, one tree hash, and M commit hashes where M is the size of the set of the tuples of email addresses and author names among the monkeys.
This is the document got me really understand Git. It's really helpful to know the internals as the surface of Git is too many to comprehend on their own.
Could be pain Tex, but I doubt it. Could be troff, but because it was easily converted to html, I doubt that to. Best bet is Markdown + some typesetter.
A nice resource in the same vein -- build a bare bones git in javascript: http://kushagragour.in/blog/2014/01/build-git-learn-git/
And finally, Linus's one page explanation of git's central concepts for the initial commit of git: https://github.com/git/git/tree/e83c5163316f89bfbde7d9ab23ca...