Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git from the Bottom Up (2009) [pdf]

ftp.newartisans.com

Post reply on HN
Print view View original

21–26 of 26 posts

Re: Git from the Bottom Up (2009) [pdf]

#21

Post by erikb »

brudgers wrote: post #7
erikb wrote: post #3

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.

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…

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

Re: Git from the Bottom Up (2009) [pdf]

#22

Post by rezzo »

jonahx wrote: post #5

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

Re: Git from the Bottom Up (2009) [pdf]

#23

Post by brudgers »

erikb wrote: post #21
brudgers wrote: post #7

Earlier quoted context omitted.

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…

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.

Re: Git from the Bottom Up (2009) [pdf]

#24

Post by davvolun »

brudgers wrote: post #13
JoshTriplett wrote: post #10

Earlier quoted context omitted.

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…

> as a belt to sport with one's lederhosen

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

Post reply on HN