Preferences


> Git is for hobby side projects. Perforce and Sapling are for adult projects.

The numbers I've seen say git has about 87-93% of the version control market share. That's just one of many reasons I think it is safe to say most professional developers disagree with you. I can understand someone prefering Perforce for their workflow (and yes, I have used it before). But saying Git is only "for hobby side projects" is just ridiculous. It has obviously proven its value for professional development work, even if it doesn't fit your personal taste.

A local minimum is a point in the design space from which any change is an improvement (but there's other designs which would be worse, if they make several larger changes). I think it's hard to make that claim about Git. You're probably referring to a local maximum, a point in the design space from which any change makes it better (but there's other designs which would be better, if they make several larger changes).

In my career, I've used Svn, Git and something I think it was called VSS. Git has definitively caused less problems, it's also been easy to teach to newbies. And I think the best feature of Git is that people really really benefit from being taught the Git models and data structures (even bootcamp juniors on their first job), because suddenly they go from a magic incantation perspective to a problem-solving perspective. I've never experienced any other software which has such a powerful mental model.

That of course doesn't mean that Mercurial is not better; I've never used it. It might be that Mercurial would have all the advantages of git and then some. But if that were so, I think it would be hard to say that Git is at a local maximum.

> something I think it was called VSS

Hmm, maybe Microsoft Visual Source Safe? I remember that. It was notorious for multiple reasons:

* Defaulted to requiring users to exclusively 'check out' files before modifying them. Meaning that if one person had checked out a file, no one else could edit that file until it was checked in again.

* Had a nasty habit of occasionally corrupting the database.

* Was rumored to be rarely or not at all used within Microsoft.

* Was so slow as to be nearly unusable if you weren't on the same LAN as the server. Not that a lot of people were working remotely back then (i.e. using a dial-up connection), but for those who were it was really quite bad.

> it's also been easy to teach to newbies

The number of guides proclaiming the ease of Git is evidence that Git is not easy. Things that are actually easy do involve countless arguments about how easy they are.

I can teach an artist or designer who has never heard of version control how to use Perforce in 10 minutes. They’ll run into corner cases, but they’ll probably never lose work or get “into a bad state”.

> A local minimum is [...]

Unless you're in ML, in which case it's a minimum of the loss function, not the utility function...

> You're probably referring to a local maximum, a point in the design space from which any change makes it better (but there's other designs which would be better, if they make several larger changes).

I think you meant "worse" for that first "better."

Git being easy to teach to newbies is an uncommon opinion. It was not clear if you meant easier than Subversion. But this would be even more uncommon.
> I've never experienced any other software which has such a powerful mental model.

I hate to be that guy, but you should spend some time with jj. I thought the same, but jj takes this model, refines it, and gives you more power with fewer primitives. If you feel this way about git, but give it an honest try, I feel like you'd appreciate it.

Or maybe not. Different people are different :)

> In my 18 years of professional dev I’ve never actually used Git professionally. Git is for hobby side projects. Perforce and Sapling are for adult projects.

I have encountered Perforce, Mercurial, and git professionally throughout my career. Considering the prominence of git in the market, it must be obvious that git does some combination of things right. I myself have found git to be solid where the other salient choices have had drawbacks.

The use of git it so widespread that it is hardly a local minimum.

*local maximum
Mercurial had its chance, and it blew it by insisting that the history is immutable and branches are heavy-weight objects (SVN-style). Turns out that's not what people want, so git won.

(And the fact that Mercurial supports history editing _now_ is irrelevant, that ship has long sailed.)

Everything is a local minima, given that you can't exhaustively prove otherwise for anything beyond the most trivial domains.
> And it’s doubly tragic because Mercurial is much better than Git. It’s VHS vs Betamax all over again.

VHS won because it was cheaper and could record longer. Fidelity was similar at the recording speeds people used in practice.

In my 25ish years I’d professional dev, I’ve used git for about 15 of them. I’ve never used Perforce and never even heard of Sapling.

It’s very likely that most if not all of the software stack you’re using to post your comment is managed with git.

I am keenly aware of how common Git is.

A whole generation of programmers have only ever known Git and GitHub. They assume that since it is the standard it must be good. This is a fallacy.

Bad things can become popular and become entrenched even when better things exist. Replacing Git today would require something not just a little better but radically better. Git was always worse than Mercurial. It won because of GitHub. If MercurialHub had been invented instead we’d all be using that and would be much happier. Alas.

> Git was always worse than Mercurial.

hard disagree. Git was always way better than Mercurial.

> It won because of GitHub.

I and most of the developers I have worked with over the years all used git for many years before ever even trying GitHub. GitHub obviously has helped adoption, but I'm not convinced that git would not have won even if GitHub had never existed.

> Git was always way better than Mercurial.

How is Git better than Mercurial in any way nevermind "always way better". Serious question.

I'd possibly accept "the original Mercurial implementation was Python which was slow". And perhaps that's why Git won rather than GitHub. But I don't think so.

So none of the stuff you’re using qualifies as “adult projects”?

I don’t object to saying we can do better than git. But saying git “is for hobby side projects” is ridiculous. It’s fine for serious projects.

Depends on how snarky I’m feeling. I’m not sure that webdev counts as wearing big boy pants if I’m feeling frisky! It’d be interesting to analyze how much of the stack used Git as its source of truth versus being mirrored by a BigTech adult VCS!

Git sucks for serious projects. It’s certainly what many people use. But I don’t think “we can do better” is a strong enough statement. Git is bad and sucks. It’s functional but bad. We can do much much better than Git.

I like to rant about Git because we will never do better unless people demand it. If people think it’s good enough then we’ll never get something better. That makes me sad.

I work at a big tech company. Everything is git. I’m not just referring to the web bits, I mean the whole OS down to the kernel.
I’m sorry for your loss :(
> Git sucks for serious projects.

again, hard disagree. I work on serious projects all day long. Git is fabulous for serious projects.

> Git was always worse than Mercurial. It won because of GitHub. If MercurialHub had been invented instead we’d all be using that and would be much happier.

MercurialHub was invented. It’s called Bitbucket, it was founded around the same time as GitHub, and it started out with Mercurial. People wanted Git, so Bitbucket was forced to switch to Git.

> People wanted Git

No. If Bitbucket competed with MercurialHub then MercurialHub would still have won and we’d all be much happier today.

Bitbucket was your desired MercurialHub. They supported Mercurial first. Then they added Git support because people wanted Git. At that point, Bitbucket users could choose between Git and Mercurial. They chose Git, so much so that Bitbucket stopped supporting Mercurial.

Look, I get that you hate Git, but people had the choice of using Mercurial or Git – on the same platform even – and they overwhelmingly chose Git. You claiming that Mercurial would win in a fair fight ignores the fact that that fight did actually happen and Mercurial lost.

This item has no comments currently.

Keyboard Shortcuts

Story Lists

j
Next story
k
Previous story
Shift+j
Last story
Shift+k
First story
o Enter
Go to story URL
c
Go to comments
u
Go to author

Navigation

Shift+t
Go to top stories
Shift+n
Go to new stories
Shift+b
Go to best stories
Shift+a
Go to Ask HN
Shift+s
Go to Show HN

Miscellaneous

?
Show this modal