Beej's Guide to Git

Same here! I was also a teenager in the mid-90s. And I was amazed by IRCd server code and bots. I bought a used copy of the book Slackware Linux unleashed w/CD-ROM and it had some networking code examples in C. I found Beej's Networking site because I was confused by a lot of that networking code. Became even more obsessed and went a deep rabbit hole. I spent a lot of time visiting different book stores hoping they had programming books. Bought Richard Stevens' amazing reference books and never looked back. Thanks for enabling my passion all these years later Beej!

[1] https://beej.us/guide/bgipc/

+1, I have almost exactly the same story!

(I didn't read the IPC guide.)

Just a quick shout-out; I was one of the many many students you taught at Lambda School, and just wanted to say your instruction was one of the highlights of my time there. Thanks for doing what you do!

Loved your Network programming guide :) !

I found your networking guide as a kid with only some scripting experience, and it served to get me into C programming in general, so I have a special fondness for it.

Appreciate the work! Neat to see you still writing pieces like this all these years later!

And still shoot yourself in the foot.

Eh, yes and no.

Git porcelain stuff's plenty good for probably 95% of users. `rebase -i` comes with a guide on which commands do what, and you could write a couple of paragraphs about how to format `git log`'s output with your own preferences and tradeoffs -- and porcelain usually includes stuff as eclectic as `git gc`, `git fsck`, and `git rev-parse` by most accounts.

Git plumbing's definitely a bit more obscure, and does a bunch of stuff on its own that you can't always easily do with porcelain commands because they're optimized for the common use cases.

TL;DR: while Git's big (huge even), a lot of what it provides is way off the beaten path for most devs.

My sense, bluntly, is that if people spent half the effort learning git that they do whining about it, no one would bother making a 30+ part guide just explaining stuff you could find in a man page.

Commits are snapshots of a tree. They have a list of ancestors (usually, but not always, just one). Tags are named pointers to a commit that don't change. Branches are named pointers to a commit that do change. The index is a tiny proto-commit still in progress that you "add" to before committing.

There. That's git. Want to know more? Don't read the guide, just google "how to I switch to a specific git commit without affecting my tree?", or "how do I commit only some of my changed files?", or "how to I copy this commit from another place into my current tree?".

The base abstractions are minimalist and easy. The things you want to do with them are elaborate and complicated. Learn the former, google the latter. Don't read guides.

With most of my guides I try to make it so you can quit reading when you feel you've read enough. No need to read the whole thing.

And on that note, I feel like the guide covers maybe 10% of Git :), but hopefully 90% of common usage.

It tells me that git is the wrong tool for the majority of people but it just happened to stick.

I did it once, I was indeed really nice, and the discussion that we did after was very cool. I put in the last slide of the presentation some questions for my colleagues answer based on the Git data model, e.g.: "Can we move a commit to another branch?" or "What guarantees that we don't have cycles in the commit graph". I was really satisfying that people came out thinking Git, not only using it!

One mistake that I see people making about Git is trying to learn more commands, more flags, more tricks, but not trying to really understand how it works. Perhaps it's your case. You know Git enough to use in your daily basis, so maybe it's time to dive into a lower level and then everything else will be natural.

I strongly suggest reading Pro Git, the official Git book by Scott Chacon and Ben Straub, available for free here: https://git-scm.com/book/en/v2.

I find it very pleasant to read and it really changed my perspective not only about Git but about how to write code in general. You don't need to read it entirely, but suggest at least these sections:

- 1.3 Getting Started - What is Git?: explains a little about snapshots and the three states

- 10.1 ~ 10.3 Plumbing and Porcelain, Git Objects and Git References: this explains Git in its lowest level, which is surprisingly simple but powerful. Those sections were enough for me to write my own "Git" (you can see it here: https://github.com/lucasoshiro/oshit)

If you do check it out and there are parts that are confusing, I'd love to hear about it.

Seems more efficient to have one reference book rather than generating entire new 20 chapter books for every person.

I also think if you are at the “don’t know what you don’t know” point of learning a topic it’s very hard to direct an AI to generate comprehensive learning material.

This is the sort of work that makes it possible for AI to be useful at all.

I view AI as a challenge. It means I have to really raise the bar. :)

I don't disagree, but since the quality of AI is largely a function of the quality of human content, there's always going to be value in well-written human content. If humans stop producing content, I think the value of AI/LLMs drop significantly as well.