←back to thread

1062 points mixto | 3 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 #
crabbone ◴[] No.42945099[source]
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.

replies(2): >>42945814 #>>42945934 #
maccard ◴[] No.42945814[source]
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.
replies(1): >>42949288 #
1. jayd16 ◴[] No.42949288[source]
Have you actually used P4 in anger?

Having to add P4 support to any script, sucks. Having to do a network operation when touching files, sucks. Many many many apps have no idea what p4 is and will never get p4 support.

Git gets out of the way.

replies(1): >>42950615 #
2. maccard ◴[] No.42950615[source]
> Have you actually used P4 in anger?

Yes. I use it every day. I've ran P4 servers that serve hundreds of GBs per day globally with both commit edges and regular proxies. I've written batch scripts, bash scripts, and tooling in python, go and C# around it.

> Having to add P4 support to any script, sucks.

I disagree. It's no worse than adding git support to something. p4 zTag isn't the most elegant thing, but it works.

> Having to do a network operation when touching files, sucks.

Does it? Is it any worse than having to keep the entire history of every file locally on your machine, including any "large files?" And git-lfs as a solution to that means you're now coupled to wherever those files are stored. Making large submits to P4 isn't the nicest experience, but it sure beats paying that price every time you clone a repo IMO.

> Many many many apps have no idea what p4 is and will never get p4 support

In the same way that many people in this thread are blaming a git gui for a problem, "that's not P4's fault". I do agree it's shit though.

> Git gets out of the way.

Until it doesn't.

replies(1): >>42954173 #
3. jayd16 ◴[] No.42954173[source]
The point is you don't need to add git support.

Yes, network traffic does suck more than spending extra disk space, especially when you need multiple workspace because P4 sucks at switching anyway.

I don't understand what you mean about cloning. If you set up LFS properly it's not much worse than a fresh P4 pull.