Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej
Your network programming guide really saved my bacon back when I was taking a networking class, I appreciate all your hard work!
Beej's Guide to Git
71–80 of 318 posts
Re: Beej's Guide to Git
#72Earlier 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?
Not realizing that git branches are cheap.
1. Create a branch from the intended destination.
2. Merge/rebase/whatever complex operation you need to do into that branch.
3. If successful merge this branch (fast forward merge) into the intended destination.
4. If unsuccessful delete the branch and start over at step 1.
Re: Beej's Guide to Git
#73Earlier 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?
Honestly? I’m not sure. Here’s the problem:
1. it’s possible to get into a bad state 2. it’s not clear what exactly that state is 3. it’s not clear how you got into that state 4. it’s not clear how to get out of it
I understand Git reasonably well. I know a good bit how it works under the hood. When I have a gitastrophe I rarely understand what I did wrong and how to avoid it in the future.
Here’s a recent post from a friend:
“ 0) clicked fetch all to make sure I had latest everything 1) right clicked on master and selected "merge master into branch" 2) made sure there were no merge errors 3) get on the master branch 4) clicked pull again because sometimes switching to branches doesn't work without it 5) right clicked on my branch and selected "merge branch into master" 6) clicked check in and push buttons
About an hour later, someone noticed that everyone's work from the past week was gone. I mean the checkins were still there in the graph, but all their code was basically gone in latest. And because my branch had many commits in it, apparently no one could just revert my merge and it took someone an hour to work out how to fix everything during which no one could touch git”
Somewhere along the way he didn’t do what he thought he did. No one could figure out what he actually did wrong. No lessons were learned from this Gitastrophe.
Re: Beej's Guide to Git
#74Earlier quoted context omitted.
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.
Internal audit said the same thing.
Quelle surprise!
Re: Beej's Guide to Git
#75Well, 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?
The guide is comprehensive, on the other extreme, this one-pager contains 90% of git commands you'll ever need: https://wizardzines.com/git-cheat-sheet.pdf
Re: Beej's Guide to Git
#76Earlier 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…
Sigh. Another git thread, another pile of posts telling me that if I would _just do the work_ to understand the underlying data structure I could finally allow myself to be swept up in the _overwhelming beauty_ of the something something something. The evidence that the git UI is awful is _overwhelming_. Yes, yes, I’m sure the people that defend it are very very very very smart, and don’t own a TV, and only listen to…
GP isn't describing the underlying data structures, they're describing the basic interface of commits, branches, and tags. The 101 stuff you have to learn regardless, for any version control, not just git. Dismissing it like this just sounds like someone who refuses to hold scissors by the handles.
Re: Beej's Guide to Git
#77Earlier quoted context omitted.
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
Skimming over it, it looks like it's just been expanded out way more than what most guides would do. Like other guides would use a paragraph or two for what this one has spread over several sections with extra examples.
Re: Beej's Guide to Git
#78I 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…
Is there a copy/video of your talk, or a similar one you recommend?
Re: Beej's Guide to Git
#79I 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 regularly conduct 2 hr long "Intro to the Git Data Model" courses at my workplace (1-2 times a year)
Does the course material (and perhaps any recordings) have any proprietary information or constraints to prevent you from sharing it publicly? Is this based on something that’s publicly available yet concise enough to fit within two hours? If yes, please share (perhaps in this thread and as a post submission on HN).
I’m asking because I believe that there can never be enough variety of training materials that handle a topic with different assumptions, analogies, focus, etc.
Re: Beej's Guide to Git
#80Earlier quoted context omitted.
Out of curiosity, what are the most common foot guns, in your opinion?
Honestly? I’m not sure. Here’s the problem: 1. it’s possible to get into a bad state 2. it’s not clear what exactly that state is 3. it’s not clear how you got into that state 4. it’s not clear how to get out of it I understand Git reasonably well. I know a good bit how it works under the hood. When I have a gitastrophe I rarely understand what I did wrong and how to avoid it in the future. Here’s a recent post from…
Well first, that's not git, that's some other GUI giving its own interface to git. The majority of the time my co-workers have a git problem, it's because their GUI tool has done something weird without telling them exactly what it did - one of theirs has a "Sync Branch" button which he'd click on whenever the IDE highlighted it, and I have no idea what that's even supposed to do, but I think it was some sort of rebase.
Without knowing for sure what was going on and whether your friend was describing it using the right verbs, I'm thinking (0) didn't pull in the changes ("fetch" instead of "pull") so (1) didn't merge in any new commits, but (4) did advance master, causing it to diverge from what was on the server. Then (6) probably decided to be helpful and did a force-push instead of a regular push so it wouldn't fail on the user. That would cause the server to have your friend's changes, but be missing anything that had been pushed to master after they started working on their branch.