Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej
Loved your Network programming guide :) !
Beej's Guide to Git
31–40 of 318 posts
Re: Beej's Guide to Git
#32I can't help but feel that Git has completely missed the forest through the trees that you can make a 30+ part guide explaining how to use it.
And still shoot yourself in the foot.
Re: Beej's Guide to Git
#33In case you missed it also on the front page Tuesday, 20+ anecdotes recommending a newer git-compatible VCS:
Jujutsu VCS: Introduction and patterns
Re: Beej's Guide to Git
#34I can't help but feel that Git has completely missed the forest through the trees that you can make a 30+ part guide explaining how to use it.
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.
Re: Beej's Guide to Git
#35Well, what's terrifying is that the guide is so long . I am aware that beej's guides are typically quite comprehensive, but the vast nuances of git truly eluded me until this. I guess Jujitsu would wind up being a much slimmer guide, or at least one that would be discoverable largely by humans?
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.
Re: Beej's Guide to Git
#36Earlier quoted context omitted.
It tells me that git is the wrong tool for the majority of people but it just happened to stick.
No. Git is a complex program but version control is an inherently complex problem that requires powerful tools. There's certain set of problems where, as a programmer, you're going to have to sit down and actually read the book. The universe doesn't owe you an easy 10 minute video solution to everything, it's an annoying educational expectation that people seem to have developed. Some things are just that difficult a…
No. Source control is not that complicated. Git is just bad. As an existence proof: Mercurial is much better and simpler.
I can teach someone who has never even heard of source control how to use Perforce in about 10 minutes. They will never shoot themselves in the foot and they will never lose work. There are certainly more advanced techniques that require additional training. But the basics are very easy.
Git makes even basic things difficult. And allows even experts to shoot their face off with a rocket launcher.
Git sucks. The best tool doesn't always win. If MercurialHub had been founded instead of GitHub we'd all be used a different tool. Alas.
Re: Beej's Guide to Git
#37Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej
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!
Re: Beej's Guide to Git
#38I have nothing but fond memories of reading Beej's guides. It's also this sort of work that's becoming less necessary with AI, for better or worse. This appears to be a crazy good guide, but I bet asking e.g. Claude to teach you about git (specific concepts or generate the whole guide outline and go wide on it) would be at least as good.
I view AI as a challenge. It means I have to really raise the bar. :)
Re: Beej's Guide to Git
#39Earlier quoted context omitted.
> Seems more efficient to have one reference book rather than generating entire new 20 chapter books for every person. The main advantage of LLMs is that you can ask specific questions about things that confuse you, which makes iterating to a correct mental model much faster. It's like having your own personal tutor at your beck and call. Good guidebooks attempt to do this statically... anticipate questions and confu…
I think a mix is the right approach. I’ve used LLMs to learn a variety of topics. I like having a good book to provide structure and a foundation to anchor my learning. Then use LLMs to explore the topics I need more help with. When it’s just a book. I find myself having questions like you mentioned. When it’s just LLMs I feel like I don’t have any structure for my mind to hold on to. I also feel like there is an art…
Agree and didn't mean to imply otherwise.
A good book by an expert is still better than LLMs at providing high-level priorities, a roadmap for new territory, and an introduction to the way practitioners think about their subject (though for many subjects LLMs are pretty good at this too). But the LLMs boost a book's effectiveness by being your individualized tutor.
Re: Beej's Guide to Git
#40I remember reading the excellent Beej's Guide to Network Programming[0] and Beej's Guide to Unix IPC[1] as a teenager, which were incredibly approachable while still having depth—fantastic reads both and very influential on the programmer I ended up being. [0] https://beej.us/guide/bgnet/ [1] https://beej.us/guide/bggit/
+1, I have almost exactly the same story!
(I didn't read the IPC guide.)