Hacker News Reader

Comment by nailer | Hacker News Reader

This won’t go anywhere even if its 20% better than git. To replace git’s network effects, you need to be 10x better.

How I think that will happen is using CRDTs against an AST to remove most merge conflicts.

If they deliver the virtual filesystem and server, this will be 10x better for large companies and large organized FOSS teams, who very often hit Git's pain points with relative ease, and the compatibility with Git from the client side means it has very easy onboarding for new users to get their feet wet. I've struggled with all these to varying degrees at almost every job and (non-solo) FOSS project I've been in; I've long wished for something like what's described here many, many times.

No joke, this might solve every major pain point I've had in mid-size-to-large teams in both the FOSS and proprietary world if it can deliver on what it says here, not to mention many issues with monorepo migration, work sharing, subproject management, etc. Many of these problems are very real but mostly ignored or we've decided to live with them.

Git is great, I'm one of the earliest GitHub users there is. I was also an early user of Darcs (which formed the theoretical basis for later competitors like Pijul -- so I'm not unfamiliar with radically different approaches), have a lot of experience with all kinds of administrative Git tasks for large repos; there's still plenty of room to fill gaps with new blood.

This won’t go anywhere even if it’s 20% better than git. To replace git’s network effects, you need to be 10x better.

Nobody is trying to replace git; that’s not a stated goal. Plus git is so entrenched, it’s not going anywhere anytime soon.

However, few companies have more gigantic code bases than Facebook, which not that long ago, had their entire monorepo [1] in Mercurial, which had certain advantages over Git at the time.

So if there’s an organization that knows the pinpoints of version control, I’d put Facebook on that list. They’ve been working on approving version control at scale for more than 8 years.

As long as it’s git-compatible, the git true believers will have nothing to worry about.

[1]: https://engineering.fb.com/2014/01/07/core-data/scaling-merc...

You may find https://pijul.org/ interesting.

And https://github.com/martinvonz/jj.

Because it is based on Git, jj is not a CRDT, it seems to be a better merge algorithm (even though the details on their algorithms are scarce).

When I say "not a CRDT" I'm obviously talking about HEAD not being a CRDT, a Git repo is append-only, so the history of a Git repo actually is a CRDT (but that's not what the comment above meant).

I think the more important thing is that jj (and hg and git) don't use the AST at all, at least not yet. Does Pijul?

Does network effect even apply if it's compatible with existing git repositories?

Looking back when the last change happened: there was a subversion integration with git, but people actually switched to git for proper decentralised version control rather than use it. Then switched to GitHub to recentralise but that’s off topic.

I remember git-svn being pretty commonly used back in the day (circa 2007). At that point a lot of open-source projects were still using svn and if you wanted to use git locally, git-svn or something similar was how you did it.

My first experience with git was using git-svn to work with my company's internal svn repository, which I did for a couple years before the company stopped using svn. There was no internal desire for decentralized version control (rather the opposite, in fact; they wanted centralized permission management and such).

Not everything that uses GitHub/BitBucket/GitLab etc. is (re)centralized. You can have an internal company hosting service and a public hosting solution, for example. I've also used the decentralized capabilities to synchronize between two computers.

There are many reasons why GitHub (or something like it) are popular, such as:

1) not having to host the infrastructure yourself (incl. hosting it on AWS/Azure/etc.)

2) discoverability -- being able to follow people/organizations creating projects you are interested in; being able to search for projects ~ having these on various websites makes it harder to discover them

3) additional functionality/capabilities like static web page hosting (great for things like personal projects), and CI/CD workflows

I think a lot of people see this and think "I'm switching as soon as possible". It might be the 10x you need (although IMO 2x would do).

People are SUPER over dealing with using Git on large repos.

Somehow that doesn't matter for FB. Yarn is not 10x better than NPM and it took off. React is.... ugh... React and it took over the whole dang industry.

> Yarn is not 10x better than NPM and it took off.

Did it? I think it had a short lived period of popularity when npm wasn't deterministic and is now mainly a novelty.

> React is.... ugh... React and it took over the whole dang industry.

Agreed there. But most people hadn't seen components before, they really were 10x better than MVC approach, even for all of React's complexity.

Reply on news.ycombinator.com