←back to thread

1062 points mixto | 2 comments | | HN request time: 0s | source
Show context
dijit ◴[] No.42941702[source]
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?

replies(3): >>42942124 #>>42942687 #>>42943687 #
vvpan ◴[] No.42942124[source]
It tells me that git is the wrong tool for the majority of people but it just happened to stick.
replies(3): >>42942293 #>>42942401 #>>42952448 #
Barrin92 ◴[] No.42942401[source]
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 and you have to learn them regardless.

replies(3): >>42942689 #>>42948250 #>>42953227 #
forrestthewoods ◴[] No.42942689[source]
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 even basic things difficult. And allows even experts to shoot their face off with a rocket launcher.

Git sucks. The best tool doesn't always win. If MercurialHub had been founded instead of GitHub we'd all be used a different tool. Alas.

replies(3): >>42942795 #>>42944069 #>>42945099 #
beej71 ◴[] No.42942795[source]
Out of curiosity, what are the most common foot guns, in your opinion?
replies(5): >>42943049 #>>42943615 #>>42943616 #>>42945900 #>>42950081 #
forrestthewoods ◴[] No.42943616{3}[source]
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 a friend:

“ 0) clicked fetch all to make sure I had latest everything 1) right clicked on master and selected "merge master into branch" 2) made sure there were no merge errors 3) get on the master branch 4) clicked pull again because sometimes switching to branches doesn't work without it 5) right clicked on my branch and selected "merge branch into master" 6) clicked check in and push buttons

About an hour later, someone noticed that everyone's work from the past week was gone. I mean the checkins were still there in the graph, but all their code was basically gone in latest. And because my branch had many commits in it, apparently no one could just revert my merge and it took someone an hour to work out how to fix everything during which no one could touch git”

Somewhere along the way he didn’t do what he thought he did. No one could figure out what he actually did wrong. No lessons were learned from this Gitastrophe.

replies(2): >>42943804 #>>42944081 #
1. Izkata ◴[] No.42943804{4}[source]
Well first, that's not git, that's some other GUI giving its own interface to git. The majority of the time my co-workers have a git problem, it's because their GUI tool has done something weird without telling them exactly what it did - one of theirs has a "Sync Branch" button which he'd click on whenever the IDE highlighted it, and I have no idea what that's even supposed to do, but I think it was some sort of rebase.

Without knowing for sure what was going on and whether your friend was describing it using the right verbs, I'm thinking (0) didn't pull in the changes ("fetch" instead of "pull") so (1) didn't merge in any new commits, but (4) did advance master, causing it to diverge from what was on the server. Then (6) probably decided to be helpful and did a force-push instead of a regular push so it wouldn't fail on the user. That would cause the server to have your friend's changes, but be missing anything that had been pushed to master after they started working on their branch.

replies(1): >>42950713 #
2. Izkata ◴[] No.42950713[source]
That (4) in my comment was supposed to be (5), way too late to fix now.