Git from the Bottom Up (2009) [pdf] | Hacker News Reader

Git from the Bottom Up (2009) [pdf]

ftp.newartisans.com

114 pointsbrudgers25 comments

Web version: http://jwiegley.github.io/git-from-the-bottom-up/

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...

I have just created EPUB and MOBI versions from the latest commit on the original book's repository (2015-08-03): https://github.com/johnrezzo/git-from-the-bottom-up-ebook

Thanks, those are great references that I'd totally forgotten about.

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.

[1]: http://www.infoq.com/presentations/Value-Values

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].

> as a belt to sport with one's lederhosen

That sounds to my American ears like the most German thing I've ever heard.

Commits are also immutable in git. But your first sentence sound like they are mutable, or not?

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.

Same here, it's the non-encapsulation of persistent structures. Learning top-bottom feels like an impatient solution that will backfire.

Talking about merges in Git always reminds me of this Linus post:

http://marc.info/?l=linux-kernel&m=139033182525831

there's clearly a balance between "octopus merges are fine" and "Christ, that's not an octopus, that's a Cthulhu merge".

(Also, GitHub's logo is reminiscent of the "octopus merge".)

Related, for visual learners, Git for ages 4 and up: https://www.youtube.com/watch?v=1ffBJ4sVUb4

this is awesome, thank you!

Seems to be down ATM. Archive link: http://web.archive.org/web/20150906053023/http://ftp.newarti...

There's also Git from the Inside Out: https://codewords.recurse.com/issues/two/git-from-the-inside...

*Part of a new publication by Recurse Center/Hacker School

Related: https://git-scm.com/book/en/v1/Git-Internals-Git-Objects (and other sections in that chapter)

This chapter was updated for the 2nd edition:

https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

My favourite introduction to Git internals is by Scott Chacon:

https://github.com/pluralsight/git-internals-pdf/releases

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.

This was the first explanation of Git that made sense to me.

What tool was used to create this document?

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.

Old but gold. This is how I learned git, and I think it's the only proper way.

Actually I did `git help tutorial` first to get started.

Reply on news.ycombinator.com