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

Beej's Guide to Git

beej.us

Post reply on HN
Print view View original

51–60 of 318 posts

Re: Beej's Guide to Git

#51

Post by o11c »

lucasoshiro wrote: post #25
elevatedastalt wrote: post #24

I regularly conduct 2 hr long "Intro to the Git Data Model" courses at my workplace (1-2 times a year). I literally take them into the .git directory and unzip the files to show how everything is just plain text representation of basic data structures. It's honestly cool to see it click in their heads. We have a basic Git cookbook we share with any new joinees so that they start committing code, but most of them just…

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!

That last question is a cryptography question in disguise; the answer is "the fact that SHA-1 collisions are still impractical for most people".

Re: Beej's Guide to Git

#52

Post by nektro »

pkage wrote: post #2

I 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] https://beej.us/guide/bgipc/

Re: Beej's Guide to Git

#53

Post by lostdog »

beej71 wrote: post #45
forrestthewoods wrote: post #36

Earlier quoted context omitted.

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…

Out of curiosity, what are the most common foot guns, in your opinion?

Messing up conflicts during a rebase, thinking I did it right, and then finalizing the rebase and losing work that accidentally disappeared. That's my most common mistake at least.

Re: Beej's Guide to Git

#58

Post by djeastm »

beej71 wrote: post #35
dijit wrote: post #3

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

>And on that note, I feel like the guide covers maybe 10% of Git

guh

I'm just going to be emailing myself versions of files with MyFile.Final.RealFinal2.txt from now on

Re: Beej's Guide to Git

#59

Post by rblatz »

chasil wrote: post #48
ajross wrote: post #43

Earlier quoted context omitted.

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…

The deal killer for me, the inescapable aspect of my users, is that they insist upon checking passwords into revision control. Because the C and PL/SQL people are on CVS, I can fix this with vi on the ,v archive. First on TFS repositories, and now with git grep I can easily find exposed passwords for many things. But it's just SQL Server! We will never be able to use git responsibly, so I will peruse this guide with…

The devs shouldn’t have access to prod credentials in the first place. That’s the real issue.

Re: Beej's Guide to Git

#60

Post by soseng »

pkage wrote: post #2

I 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/

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!
Post reply on HN