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

131–140 of 318 posts

Re: Beej's Guide to Git

#131

Post by sundarurfriend »

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…

> As long as your mental model is right, the commands are not a big deal.

A priori, I would have assumed this was one of those "just understand how every layer and every part of Linux works, and using Linux is easy" type arguments people used to make in the 90s - i.e. theoretically true, practically infeasible for most people.

Thankfully, I was lucky enough to come across a video explaining (some of) the git internal model early on, and it really doesn't take that much or that deep a knowledge of the internals for it to make a big difference. I'd say I know maybe 5% of how git works, and that already gave me a much better understanding of what the commands do and how to use them.

Re: Beej's Guide to Git

#132

Post by maccard »

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

Not at all. Not in the least. The worst part about Git is the bad defaults. Seconded only by mismanaged storage. Or maybe being designed for the use-case most of its users will never have. Or maybe horrible authentication mechanism. Or maybe the lack of bug-tracker or any sensible feedback from its developers. None of this can be helped by the GUI. In fact, beside Magit, any sort of front-end to Git I've seen is hand…

I use the IntelliJ family of IDEs and the number of times I’ve had to reach for the cli for day to day use is incredibly close to 0. It handles GitHub auth, PR’s, branching and merging, rebase, and local branch switching pretty much effortlessly

Re: Beej's Guide to Git

#133

Post by maccard »

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 and perforce are a better solution for anything with a centralised repo IMO

Re: Beej's Guide to Git

#134

Post by _puk »

globular-toast wrote: post #127
wruza wrote: post #103

Earlier quoted context omitted.

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.

Ah, we're holding it wrong. Got it.

Re: Beej's Guide to Git

#136

Post by maccard »

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

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

If the tool is designed to support the use case of the 1% with concessions for the other 99%, the tool is badly designed.

Git is designed for the case where you have multiple remotes with no central authority. Except that’s not how any project I’ve _ever_ worked on functions in reality. It makes sense for some applications, but if I say that I run Linux, there’s an assumption that I’m running something compiled from https://github.com/torvalds/linux - I.e. there is a central space.

I’ve used git and perforce in anger for a decade, in teams of 1 to 150+ (with a brief blip in the middle where I tried plasticscm which was a mistake), and I’ve been the “git guy” on teams during that time. If git’s defaults were tweaked for “one origin, probably authoritative” and it had better authentication support out of the box it would be a significantly better experience for 99% of people. Those 1% of people who are left over are going to customise their config anyway, so make them add the distributed-defaults=true flag and the rest of us can get on with our work.

Re: Beej's Guide to Git

#137

Post by sampullman »

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

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

I'm not totally sure what you mean by "non-automated" here, can you clarify? I have managed repos for small teams, that's actually the majority of my experience with it.

I do deal with multiple remotes quite often and haven't encountered issues. You're right about submodules, I avoid setting up projects with them, even at the expense of more manual work or complicated automation.

I'm definitely not using it as a substitute for rsync - I do prefer to put rules in place to avoid editing (shared) history, for obvious reasons.

Re: Beej's Guide to Git

#138

Post by maccard »

rswail wrote: post #115
chasil wrote: post #48

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

Sounds like you need a pre-commit hook to check.

Pre commit hooks aren’t enforcable. People need to opt in to them, and the people who opt in to them are the people who will check for passwords before they commit.

Re: Beej's Guide to Git

#139

Post by maccard »

crabbone wrote: post #124
stephen_g wrote: post #16

Earlier quoted context omitted.

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

> I don't know why Git won the VCS contest

Because GitHub offered free git hosting, and heroku came along and offered free hosting that was pretty much point and go.

Combined, you all of a sudden went from needing a sysadmin and two servers (this was pre containers), and the sysadmjn skills to operate SVN and your web app, to “it’s now free and it auto deploys when I commit”.

Re: Beej's Guide to Git

#140

Post by maccard »

gitgood wrote: post #90
forrestthewoods wrote: post #73

Earlier quoted context omitted.

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…

And yet only git has these problems. I work with artists and designers - non technical people - all day. 10 minutes with p4v is all they need to be able to check in, update, roll back bad changes, and shelve to share with others, and even these people who manage to get their computers into the most unbelievable of states can do that without breaking their workspace and needing help.
Post reply on HN