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

141–150 of 318 posts

Re: Beej's Guide to Git

#141

Post by maccard »

crabbone wrote: post #125
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…

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…

Why does git get a free pass for shitty defaults but perforce doesn’t? Perforce long predates git, and the checkout operation (which can be done on save with any modern editor) fixes that immediately.

Re: Beej's Guide to Git

#142

Post by maccard »

rblatz wrote: post #63
lostdog wrote: post #53

Earlier quoted context omitted.

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.

Find your last entry before the rebase using the reflog and reset your local branch to that entry. The work isn’t lost, it is sitting right there.

> Find your last entry before the rebase using the reflog and reset your local branch to that entry.

You shouldn’t ever need to go to the reflog unless you’re in an exceptional case, and fit makes it very very easy to get into that exceptional case.

Re: Beej's Guide to Git

#143

Post by maccard »

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?

How do switch to a branch? (Note that you need to fetch before you switch. Also switch is experimental but it’s not really)

How do I undo a change and get it to other people on the team?

- follow up, What happens if someone has made an unrelaydx change since?

- someone has committed an enormous change and I want the commit immediately after it but the enormous change doesn’t affect me. How do I get that single file without needing the mega change.

- someone has committed a mega change and pushed it to main, and it’s busted. How do I put my perfectly functioning feature in while i wait for the west coast to wake up and fix it?

I don’t need an explanation on how to solve these issues, I am perfectly able to. But these are daily workflow issues that hit requires you to use external tools, and change entire development processes to work around. And trying to skirt them is a guaranteed one way ticket to a busted workspace

Re: Beej's Guide to Git

#144

Post by forrestthewoods »

crabbone wrote: post #125
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…

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 Perforce is exceedingly simple to teach someone. And it doesn't require a 193 page guide. I can teach artists and designers how to use Perforce and not lose their work. A senior engineer who is a Git expert can still shoot themselves in the foot and get into really nasty situations they may or may not be able to get out of.

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

Re: Beej's Guide to Git

#145

Post by randstring »

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/

Indeed, my first steps in network programming years ago were with the help of this excellent guide.

Re: Beej's Guide to Git

#146

Post by crabbone »

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…

So, there's a difference between how problems are common, how many of them are there, and how hard it is to deal with them.

So, is it possible to deal with Perforce marking files read-only? -- Yes. And it's not complicated, but the whole idea that that how the system should work is stupid. The problem is, however, exceptionally common. In my days working with Perforce there hadn't been a day when this problem didn't rear its ugly head.

So, maybe Perforce is scoring better on some metric, but in the day-to-day it generates so much hatred towards itself that I don't care if it can handle big files better than Git does. I only need to handle big files maybe a few times a year. And I prefer to get frustrated only twice or three times a year than to be fuming every time I have to touch files in my project.

Re: Beej's Guide to Git

#147

Post by ssivark »

ajross wrote: post #43
scrapcode wrote: post #26

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

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…

> 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 is a tiny proto-commit still in progress that you "add" to before committing.

This is about as useful as "A monad is just a monoid in the category of endofunctors."

It's basically a lot of words which make zero sense for a user starting to use git -- even if it happens to be the most succinct explanation once they've understood git.

> The base abstractions are minimalist and easy. The things you want to do with them are elaborate and complicated. Learn the former, google the latter.

You can't really learn the former -- you can't even see it till you've experienced it for a while. The typical user groks what it means after that experience. Correction, actually: the typical user simply gives up in abject frustration. The user who survived many months of using a tool they don't understand might finally be enlightened about the elegant conceptual model of git.

Re: Beej's Guide to Git

#148

Post by aidos »

beej71 wrote: post #30

Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej

Not wrong, but since you’re mentioning vim in the context of git, might be worth adding :cq as a way to exit with a non-zero status to prevent git from finishing the commit / operation.

Re: Beej's Guide to Git

#149

Post by danw1979 »

beej71 wrote: post #30

Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej

Thank you for this Beej!

Along with many others here, your network programming guide helped me so much back in the early days of my education and career. So thanks for that too…

Re: Beej's Guide to Git

#150

Post by agumonkey »

20k wrote: post #64
scrapcode wrote: post #26

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

Honestly, 99% of the pain of git is simply because people use it through the CLI. If you use tortoisegit or a visual tool, you don't need to worry about any of this because its self explanatory, and it becomes trivial to use Learning git like this is honestly just hampering yourself

depends, you could live on a UI for a start, but script git cli gives you very high speed.. it's kind of a timeline database for your code
Post reply on HN