←back to thread

1062 points mixto | 7 comments | | HN request time: 0s | source | bottom
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 #
1. lostdog ◴[] No.42943049{3}[source]
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.
replies(1): >>42943282 #
2. rblatz ◴[] No.42943282[source]
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.

replies(1): >>42945832 #
3. maccard ◴[] No.42945832[source]
> 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.

replies(1): >>42948685 #
4. diggan ◴[] No.42948685{3}[source]
> You shouldn’t ever need to go to the reflog unless you’re in an exceptional case

If "loosing your work and it's not in the git log" isn't an exceptional case, what exactly is a "exceptional case"?

replies(1): >>42950649 #
5. maccard ◴[] No.42950649{4}[source]
> If "loosing your work and it's not in the git log" isn't an exceptional case, what exactly is a "exceptional case"?

Losing your work should be exceptional. It's very, very easy to fuck a rebase up, and rebasing is (like it or lump it) a common operation. You shouldn't one step away from an exceptional case from a daily operation.

replies(2): >>42950908 #>>42975853 #
6. diggan ◴[] No.42950908{5}[source]
Powerful tools have powerful consequences, case in point: with `rm` you're always one mistake away from blowing away large parts of your work.
7. _proofs ◴[] No.42975853{5}[source]
this is solved by branching your feature again and rebasing from that or the feature original in case the rebase gets fucked.

you don't have to treat rebases or merges as this black hole of "i have no recourse for not getting it perfect the first time".