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

81–90 of 318 posts

Re: Beej's Guide to Git

#81

Post by appleaday1 »

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.

can I repost this on leddit

Re: Beej's Guide to Git

#82

Post by billdueber »

Izkata wrote: post #76
billdueber wrote: post #70

Earlier quoted context omitted.

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.

You’re right, of course, and I apologize to GP for conflating what they were saying with what I, to be fair, do often see in these threads.

Like others in these comments, I can use it just fine right up until I can’t. Then it’s back to the mini, many, many posts and questions and tutorials, sprawled across the Internet to try and solve whatever the issue is. JJ has shown that a better chrome can be put over the underlying model, And it’s frustrating to me that we are all collectively, apparently, expected to put up with a tool that generates so much confusion seemingly regardless of brilliance or expertise

Re: Beej's Guide to Git

#83

Post by ajross »

billdueber wrote: post #70
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…

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…

Pretty much, yeah. Just do the work. It's not nearly as hard as whatever it is you're committing into it, I promise. Continuing to mock it via florid metaphor doesn't help anyone at this point.

Re: Beej's Guide to Git

#84

Post by valenterry »

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…

Share your video!

Re: Beej's Guide to Git

#86

Post by gitgood »

ajross wrote: post #83
billdueber wrote: post #70

Earlier quoted context omitted.

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…

Pretty much, yeah. Just do the work. It's not nearly as hard as whatever it is you're committing into it, I promise. Continuing to mock it via florid metaphor doesn't help anyone at this point.

I'm always kind of aghast at the number of people who not only don't know git, but who cannot or will not learn it over years, or even decades.

Listen, I'm not that smart, and I managed to figure out how to solve even gnarly git issues one summer during an internship... 11 years ago? Ish? Now, I know git well, and not just "the three commands". I would be, honestly, so ashamed if it were a decade on and I still hadn't committed to learning this fundamental tool.

Version control is a hard problem, fundamentally, and a tool for experts will always take more effort to understand. I mean, aren't we supposed to be the software experts? If people can't learn git, I wouldn't trust them with the even harder parts of software development.

But this is a common attitude in industry now, unfortunately: a petulant demand for things to be easier, and for someone else to do the learning. Is it any wonder software today is so bad?

Re: Beej's Guide to Git

#87

Post by gitgood »

billdueber wrote: post #70
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…

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…

I don't struggle with git, and I can assure you, I am not brilliant. I do, however, refuse to give up when something seems hard, and I refuse to ask the computer to be easier for me. (Understandably, I started programming computers to make them do what I wanted them to do, not to sit and whine when they didn't.)

Re: Beej's Guide to Git

#88

Post by gitgood »

djeastm wrote: post #58
beej71 wrote: post #35

Earlier 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

[flagged]

Re: Beej's Guide to Git

#89

Post by gitgood »

forrestthewoods wrote: post #36
Barrin92 wrote: post #18

Earlier quoted context omitted.

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…

You're welcome to switch back to CVS or RCS at any time. You're also welcome to deal with their specific tradeoffs.

Re: Beej's Guide to Git

#90

Post by gitgood »

forrestthewoods wrote: post #73
beej71 wrote: post #45

Earlier 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…

You've just described computers. It's possible to get into a bad state because git can't read your mind, and, at the end of the day, it is incumbent upon you, the programmer, to make the computer do what you want. That is our responsibility as practitioners.

You need to think about what you're actually trying to accomplish, and that requires having a mental model of how the tool works. And no, I don't mean under the hood, I mean stuff like "what does a rebase do?" and "how do branches work?"

The Git Book is a great resource for this. I recommend reading it and trying the examples over and over until they stick. I promise, git is not inscrutable.

Post reply on HN