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

221–230 of 318 posts

Re: Beej's Guide to Git

#221

Post by jayd16 »

forrestthewoods wrote: post #144
crabbone wrote: post #125

Earlier quoted context omitted.

Why I agree with many points you make... let's keep Perforce out of it. The amount of damage that program done to my source code, and the amount of pain caused by it in daily use tells me that 10 minutes will not cut it. Here's a simple example of how people shoot themselves in the foot with Perforce all the time: it makes files you edit read-only, and then you run with your pants on fire trying to figure out how to…

You could have marked the file as not read-only and later reconciled. Or you could have checked the file out of Perforce. You would have had a merge conflict either way. I mean I haven't even talked about how Git can't handle large files. And no Git LFS doesn't count. And Git doesn't even pretend to have a solution to file locking. I'm not saying Perforce is perfect. There's numerous things Git does better. But Perfo…

Why doesn't LFS count? It handles locking just as well as p4, too.

A good git gui works as well as p4v (and usually far less buggy).

The major difference in my eyes is that p4 can enforce more settings from the server. It's easier to get artists set up in p4 than git.

> There's a reason that like 105% of AAA game dev uses Perforce.

Irony of ironies, Unreal is distributed with git but largely uses p4.

P4 is dominant but I feel like a lot of that is momentum. Making a Unity game with git is pretty easy. Some Unreal tooling is built around p4 only but not really for any technical reasons.

Re: Beej's Guide to Git

#222

Post by wruza »

ajross wrote: post #188
wruza wrote: post #116

Earlier quoted context omitted.

If people can't learn git, I wouldn't trust them with the even harder parts of software development. This idea breaks under pressure. People have limited concentration and the more you demand for daily routine, the less there’s left for the actual job. This argument only makes sense in a relaxed setting with lots of time and coffee breaks. But all these problems tend to happen at friday evening when you’re expected t…

> Nowadays all we have is important dudes with pseudo-deep knowledge of git, css, framework-of-the-month and a collection of playbooks, who cannot make a db-enabled hello username message box in less than a day. Interestingly that is exactly the opposite of my experience. Git is a practical tool with practical appeal to people who want to do practical things. Egghead gedankentheorists hate it, as evidenced by this ve…

People, whom I knew since these times and who really like getting stuff done and have done it much, all facepalmed when seen things like git, webdev, etc. Getting stuff done is not performing hundreds of technical operations and thinking “good, I’m so skilled”. It’s actually getting it done. I can almost guarantee that it’s a guy with far better predictor skills who will deliver mvp a month later than everyone else. Been through this countless times.

Re: Beej's Guide to Git

#223

Post by jjice »

Oh my goodness, this is a huge treat. His class networking programming guide sits at one of my top books of all time. Well written, informative, concise, and legitimately get you to chuckle out loud at points.

Edit: Does anyone know a good way to convert one of the HTML pages into an epub for reading on an ereader? The PDFs will definitely work, but wanted to see if anyone knew of any tools for HTML -> EPUB conversion.

Re: Beej's Guide to Git

#224

Post by namaria »

rco8786 wrote: post #6

I 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 don't get this type of attitude. Surely using the source signal, before an LLM add noise would be much preferable. Besides, there seems to be heavily diminishing returns to de-noising LLM output, and even a hard barrier to how much we can denoise it. Yet people claim they prefer the noisy data and don't consider the risk that they are learning the noise instead of the signal because they have by definition no way of knowing what is signal and what is noise when they ask an LLM to teach them something. Because the noise is friendly sounding and on demand?

Wild.

Re: Beej's Guide to Git

#225

Post by foobarbaz33 »

jaapz wrote: post #168
foobarbaz33 wrote: post #104

Earlier quoted context omitted.

> I find it hard to judge when things are in a good enough state to commit Work in a feature branch. Commit often. Squash away the junk commits at the end. > ...and especially good enough to have a title. Who needs a title? It's perfectly fine to rapid-fire commits with no comment, to create quick save points as you work. Bind to a key in your editor. I treat commits in a private branch the same as the undo log of th…

If I had 5 cents for every commit in a feature branch with the commit message "wip"...

You should have 0 cents. Squash and chill is the way to go.

Re: Beej's Guide to Git

#226

Post by RohMin »

diggan wrote: post #194
Sxubas wrote: post #61

> The Old Command: git checkout I didn't even know git switch existed, let alone git checkout was considered the old alternative. I feel old. To be fair I started learning git a little less than 10 years ago but woah, I can't express how it feels that someone learning git today will be confused of why I use git checkout. Like using old fashioned language. More on topic, this guide would've been super useful when I wa…

> I didn't even know git switch existed, let alone git checkout was considered the old alternative. I feel old. I don't think "git checkout" is considered the "old alternative", at least not yet. Last time I checked, `switch` is still experimental, I haven't even considered moving away from the workflows/commands I first learned when I picked up Git ~15 years ago. Everything I want to do still works exactly the same…

git switch focuses on switching branches while git checkout extends further than that

Re: Beej's Guide to Git

#227

Post by m_niedoba »

jayd16 wrote: post #221
forrestthewoods wrote: post #144

Earlier quoted context omitted.

You could have marked the file as not read-only and later reconciled. Or you could have checked the file out of Perforce. You would have had a merge conflict either way. I mean I haven't even talked about how Git can't handle large files. And no Git LFS doesn't count. And Git doesn't even pretend to have a solution to file locking. I'm not saying Perforce is perfect. There's numerous things Git does better. But Perfo…

Why doesn't LFS count? It handles locking just as well as p4, too. A good git gui works as well as p4v (and usually far less buggy). The major difference in my eyes is that p4 can enforce more settings from the server. It's easier to get artists set up in p4 than git. > There's a reason that like 105% of AAA game dev uses Perforce. Irony of ironies, Unreal is distributed with git but largely uses p4. P4 is dominant b…

There are Git-based solutions for that. One of them is Anchorpoint, which is basically a centralized layer on top of Git for file locking.

File locking is one of the reasons why vanilla Git is not that popular in game dev. It only exists with Git LFS and it is not really easy to use or reliable.

Re: Beej's Guide to Git

#228

Post by Pxtl »

Happy to see `git switch` mentioned, I've been trying to use it. The error message with the helpful advice on how to get it to check out headless tags and commits I hadn't seen before though - I'd been falling back to `checkout` for those cases.

Re: Beej's Guide to Git

#230

Post by Pxtl »

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?

offhand:

1) The fact that "fetch" doesn't happen automatically in the "chrome" commands.

2) naive use of "git merge" results in history that's a cyclopean horror. For example, caring about the "left" and "right" parents of a commit.

3) rerere isn't enabled by default so if you're merging from upstream constantly you're having to re-resolve same conflicts, every time is an opportunity to screw up.

4) a culture of keeping a clean history but cleaning history is destructive and painful for other users of the same branch.

5) git merge merges from local (stale) branch by default, so when merging from upstream to get new commits you have to remember to `git merge origin/main` instead of `git merge main`. Also see (1).

6) using submodules. At all.

Post reply on HN