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

121–130 of 318 posts

Re: Beej's Guide to Git

#121

Post by crabbone »

sampullman wrote: post #91
ujkiolp wrote: post #50

Earlier quoted context omitted.

not my experience - almost always some edge case leads me to a git rabbit hole tldr: even if you never plan to use anything advanced, you’ll end up in some weird situation where you need to do something even if you’re in the “95% of the users” no shade, yes ofc you “could this, could that” to make things work and we have been stuck with this for so long that an alternative doesn’t even seem plausible

I can't remember the last time I ended up in a weird situation, I stick to basic options with init,clone,fetch,checkout,branch,commit,rebase,remote,log,stash,cherry-pick,blame,config. It did take maybe a year or so to develop the mental model of the how commands map to the underlying structure of commits, and another few years to avoid footguns (like always "push --force-with-lease"). So I think it is probably too co…

You are using Git in a non-automated way, basically, as a substitute for rsync (you never edit history, you only append to it, you don't deal with a possibility of multiple remotes, you don't deal with modular projects and you don't automate anything).

At least, this is what it looks like from your own description. This is, probably, what most people do with it most of the time. And the weird corners will be found when they need to automate things, or when they want to deal with modular repositories, or history rewrites. These aren't everyday tasks / not for everyone on the team, but, these things do happen, especially in smaller teams, where there's no dedicated infra person or group these can be delegated to.

Re: Beej's Guide to Git

#122

Post by [deleted] »

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

[deleted]

Re: Beej's Guide to Git

#123

Post by sunshowers »

gitgood wrote: post #89
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…

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

Why not switch forward to Jujutsu? It's simpler and more powerful than Git.

Re: Beej's Guide to Git

#124

Post by crabbone »

stephen_g wrote: post #16
vvpan wrote: post #14

Earlier quoted context omitted.

It tells me that git is the wrong tool for the majority of people but it just happened to stick.

I think it's probably the opposite, Git has amassed a lot of complexity because it's been adapted to being a tool that is able to can satisfy the majority of requirements. I've never found that I need to touch most of it in the 15 or so years I've been using it, but it's there if your project needs it.

Nope. It was initially built for the use-case most people will never have: multiple remotes that work on a project with multiple similar products each with its own set of differences from the others, with emphasis and dependency on Unix tools and text-only emails.

Most Git users will never have more than one remote per project, and so will only have a single product built from their source code. Probably wouldn't even know how to configure their mua to send text-only emails, in case that option is even available to them, and would struggle with basic Unix utilities like Vim and diff.

I don't know why Git won the VCS contest. But, I'm afraid, as with many such wins, there wasn't a clear rational reason why it should have won. It didn't make some of the obvious bad decisions which would disqualify it, but so did a few others. My take on this is that communication tools naturally gravitate towards monopoly, so, if one starts to win even slightly, the win will become a landslide win.

Re: Beej's Guide to Git

#125

Post by crabbone »

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…

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 save your changes, because the system won't let you do that. And then you do something dumb, like copy the contents of the file you aren't able to save someplace else, and then try to incorporate those changes back once you've dealt with the file that Perforce wouldn't save. And then end up with a merge conflict just working with your one single change that you are trying to add to your branch.

I never regretted never having to touch Perforce ever again. Just no.

Re: Beej's Guide to Git

#126

Post by kortilla »

ujkiolp wrote: post #100
sampullman wrote: post #91

Earlier quoted context omitted.

I can't remember the last time I ended up in a weird situation, I stick to basic options with init,clone,fetch,checkout,branch,commit,rebase,remote,log,stash,cherry-pick,blame,config. It did take maybe a year or so to develop the mental model of the how commands map to the underlying structure of commits, and another few years to avoid footguns (like always "push --force-with-lease"). So I think it is probably too co…

>It did take maybe a year or so we have normalized this for git - a tool to store versions of text. That’s the problem

Maybe you’re young, but git is better than all of the other shit before it.

Try to come up with something simpler than git, and you’ll end up with something like SVN or CVS that struggled with more than a couple of people working on the same files.

Try to make something that is more content aware, and you’ll find out how git got its name in the first place.

Re: Beej's Guide to Git

#127

Post by globular-toast »

wruza wrote: post #103
20k wrote: post #64

Earlier quoted context omitted.

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

I’ve seen tortoise users break their repo, struggle to understand the issue and then push it through, making it everyone’s problem. Git language is screwed, you cannot unscrew it with a right-click gui because you basically click some latin-looking hieroglyphs that you don’t know either way.

I highly doubt tortoise or any tool can "break" a repo. This might be a sign that you don't understand git either. Now I'm sure it can lead to people who don't know what they're doing doing the wrong thing, but if they're allowed to push somewhere and make it someone else's problem, that's not their fault. They've been forced to use git, so there should be someone else who actually understands git.

Re: Beej's Guide to Git

#128

Post by nextaccountic »

kortilla wrote: post #126
ujkiolp wrote: post #100

Earlier quoted context omitted.

>It did take maybe a year or so we have normalized this for git - a tool to store versions of text. That’s the problem

Maybe you’re young, but git is better than all of the other shit before it. Try to come up with something simpler than git, and you’ll end up with something like SVN or CVS that struggled with more than a couple of people working on the same files. Try to make something that is more content aware, and you’ll find out how git got its name in the first place.

Mercurial is simpler than git. It is (or was) just too damn slow

Re: Beej's Guide to Git

#129

Post by forrestthewoods »

sunshowers wrote: post #123
gitgood wrote: post #89

Earlier quoted context omitted.

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

Why not switch forward to Jujutsu? It's simpler and more powerful than Git.

I've been using Jujutsu a little and over the weekend lost a bunch of files. I'd been working happily in an anonymous branch. I had a bunch of content in a thirdparty folder that was hidden by .gitignore. I couldn't figure out how to merge my anonymous branch into master. Somehow wound up on the old master and it deleted all of my gitignored files. Then jj status got totally fubar and couldn't complete in under 5 minutes because something something 7500 files (everything that got deleted, it was compiler toolchains).

It was a disaster. Literally the most important thing for any VCS tool is to never ever delete file I don't want deleted. No more Jujutsu for me.

Someday someone will invent a VCS tool that doesn't suck. Today is not that day.

Re: Beej's Guide to Git

#130

Post by JetSetIlly »

beej71 wrote: post #30

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

Beej, your Guide to Network Programming helped me through my early UNIX career. In fact, your guide was so influential to so many people, it very quickly became recommended reading in my university's network course.

I'm delighted to see that you're still active and still producing guides. Well done!

Post reply on HN