Hacker News Reader

Comment by oblio | Hacker News Reader

> Don't focus too much on "git complexity" as most people already know git so it just creates an argument.

I'd say this phrase is both right and wrong.

It's right in the sense that it creates an argument.

It's wrong in that it creates an argument with the peanut gallery of git experts. But guess what, most people using git are not experts. They're software developers who don't want to learn the intricacies of git (probably most software developers out there), they're software development adjacent folks (think data scientists, etc) who for sure don't want to learn the intricacies of git, etc.

The "common person" using git will most likely resonate on the "git complexity" argument.

View on HN

> peanut gallery of git experts

There are people who use git for its original purpose (kernel devs and very few others) and then there is the remaining 99% of people who essentially use “github flavored git”, using only three or four git subcommands and for the most part never needing to understand its intricacies.

Unfortunately, although they are using git-the-chainsaw-shotgun with all the safeties on, it’s nonetheless a chainsaw shotgun and sometimes they’ll run into issues where they or somebody in their company needs to be an expert and figure out how to un-scramble an egg, so to speak.

If a new VCS can solve the 99% case and never need users to fall back to understanding nitty gritty details, it could very well have strong takeup especially among people who don’t give a crap about what VCS they’re using as long as it gets out of the way and doesn’t make them think (game devs, data folks, etc).

I see 2 huge barriers for a new commercial VCS:

1. Devs don't like to pay for core tools. And VCSes need network effects.

2. VCSes seem to be really hard.

As someone who is making one (not Diversion), I agree with both of your points.

Do you think that a VCS that solves the large file problem and binary file problem could succeed?

Totally agree, it won't be easy. Companies do pay for GitHub/GitLab/Perforce though, and for indie devs there's the free tier. I think what made git really take off is actually GitHub's free tier/OS hosting, and not git itself being free (at least for parts of the market, and I might be wrong).

100% correct about VCS development, it's much harder than one can expect.

> Companies do pay for GitHub/GitLab/Perforce though

Those products also provide a huge amount of other value and functionality (though at a high price).

As someone who worked at a (mobile) game dev studio, this "what if Dropbox but Git?" product design really hits for me. Teaching our artists to use Google Drive or Team Drives was easy, but the functionality isn't there. Teaching them to use SVN was a nightmare (because SVN workflows are a nightmare) but the functionality is... also not really there?

Give me either a local installation that I can set up in my office or a local proxy to reduce download speeds (or peer-to-peer on local network, the way Dropbox does it) and I could see this being beneficial for a lot of especially smaller studios.

> If a new VCS can solve the 99% case and never need users to fall back to understanding nitty gritty details

Mercurial was a bit like that? Yet it didn’t stand a chance against git regardless

Learn your tools or one day you’ll lose a finger, or worse, your life.

— high school shop class

Yet software is not a chainsaw and a huge amount of people never learn to use their software tools. Especially since they're 100x more complex than hardware tools and nobody has time to master everything.

If you are using a chainsaw in a wood shop, you are probably doing something wrong. The saying “learn your tools” means to spend some time learning your options and what is available to you, learning the “gotchas” and why. Woodworking tools are rather complex with “gotchas” that will kill you in less than a hundred ms.

Using Git isn’t much more complex than using a lathe (simpler even, as you can get by with no skill and rote memorization). Taking a weekend to learn the data structures, and how everything fits together is not a hard ask. Especially since you literally only have to do it once in your entire career.

> Taking a weekend to learn the data structures, and how everything fits together is not a hard ask. Especially since you literally only have to do it once in your entire career.

Like all simplifications, this is false. If all you do for years after is commit, push, merge, you'll forget.

Especially since you'll need those brain cells to learn the new CPU/GPU architecture, the new JavaScript framework, the new corporate security policy, the docs from your internal architecture team, etc.

Nobody's life revolves around intricate VCS details.

You don’t need to memorize it for life. Jeez man, don’t be so hard on yourself.

The point is, you know what is possible. You know what is impossible. 12 years later, something happens and you go … hmm, I used to know what is going on. I think I need to search for something about git-tree or something?

The point is, you know what to search for, a starting point. You don’t just reach for git cherry-pick, but realize you can use git rebase --onto to copy/paste an entire branch. You don’t worry about merge conflicts because you only have to do it once with rerere. You learn git reflog will remind you what branch you were working on this morning before you got pulled into some shenanigans in prod. You can set up automation with global hooks. There’s so much you can know to do less work and you only need to remember the parts that are valuable to you.

After learning git about 5 years ago stuff like ^ is all second nature to me, for nearly 10 years since switching from SVN. My first 5 years was just like you said. Commit, pull, commit, pull. I didn’t even know it could do anything else and I was worse for it.

It is just a tough argument to make: the thing you have been using for your entire career and used almost everywhere is suddenly too complex.

Ummm... A lot of people just endure using git. Go to the average enterprise software shop, the ones where people don't code for fun in their spare time, and ask around.

There are a lot more of those devs than unicorn and FAANG devs.

Why aren't these teams choosing something else then? If everyone on the team dislikes git, switch to mercurial or something else.

Git might be the best thing there is today (outside of very large companies or environments with large binaries). It doesn't mean that'll always be the case... There were other VCSs before git, and there will be after.

Because often it’s not the team that chooses, but tooling is instead standardized across the enterprise. And enterprises like to make the “safe” choice of choosing what’s most popular. And then there’s the whole aspect that you have to know some basic Git anyway to debug your way through the open source code you use (maybe not for JavaScript/NPM, I don’t know). Git also happens to currently be the most interoperable with other kinds of tooling, from CI to IDEs, so not using Git makes your life harder in ways unrelated to its inherent qualities. It’s a network effect in multiple dimensions.

How did it get so popular if disliked by the majority of dev?

Because generally people picking the tools are not majority of dev. They are architects or Senior Developers who do enjoy learning new things.

Also, git generally does just work and most IDE/Source Control Systems take care of basic operation of pull/branch/commit/push/open PR.

I suppose. It might seem a bit perverse after all if the non-engaged, uninterested in coding, clock puncher devs got to make all the decisions.

Popular as in “everyone is using it”, not necessarily “everyone is fond of it”. How did Jira become so popular? The dynamics that lead to such outcomes are interesting, but hardly unusual.

I use git because other people use git, and ultimately I try to accommodate the tools that my peers are going to be used to. But I do think it's too complex (by a lot), and if I was running some kind of dictatorship I would never touch git again. Frankly, I think that git is a significantly worse tool than svn was for most use cases.

I like git better than svn personally. But, svn is better at managing large binary files.

Reply on news.ycombinator.com