Hacker News new | ask | show | jobs
by midenginedcoupe 1214 days ago
Or we could get off the cargo-cult need to use git on every single project everywhere regardless of how suitable it is for that team's needs.

If your tool of choice is so actively user-hostile that it needs another tool on top to understand it for you, then perhaps you've picked the wrong tool. I don't need to read the "vi book" to understand how to perform basic edits to my files without borking it in ways that just deleting the whole thing and restoring from backup is the easiest way out. Why should it be the case for my revision control system?

Why a revision control system designed for a de-centralised team sharing patches over email has become the industry standard for centralised teams not sharing patches over email is a mystery, and I suspect one we'll look back on in 10 years or so and wonder what on earth we were thinking.

2 comments

The network effect is so huge it trumps on everything else.

I'd like to use pijul. I can't because I work with other people. Can I use it when I'm not working with other people? Well I can, but why should I care about a tool that better handles merge conflicts if I have nobody to conflict with?

Some tools are more sensible to others to the network effect.

We already are slaves to the network effect even for tools that we don't technically require being the same as the one your colleagues you, let alone those that do require that.

Sure. The network effect explains why it's the defacto standard now, but not necessarily how it got there. And, ironically, I use git for all my projects for exactly the same reasons.

Pijul looks interesting though.

Simple: it's because it's the most widely supported system.

Want to recommend me a better VCS? Feel free, as long as it has a cross-platform open source client, a nice GUI, is supported in my IDE, there's a company offering to host repos for free along with a nice web viewer, it's supported by a CI system comparable to what I use now (including giving me free time on shared runners)...

Isn't that just a reflection of its current status as the defacto standard, rather than an explanation for how it got there?

I've been in two teams that spent time to evaluate revision control systems on their own merits and Mercurial came out on top both times. At that time, bitbucket supported it, as did IntelliJ. Ironically I can't vouch for whether that was the right decision at the time as the network effect meant they went with git anyway!