Live data from Hacker News

Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

news.ycombinator.com

101–110 of 440 posts

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#101
1. git is not hard if you learn it

2. I regularly see people storing multiple gigabyte files in git.. I don't understand your issue with large files.

3. cloud native? why? part of the point of git is to have a repo decentralized away from centralized clouds onto dev's machines, if your data scientist broke git then that means your main branch configuration is off, no one else had that cloned onto their machines, and the rest of you don't know how to recover lost data which is stored in the reflog.... even ignoring the lack of simple CICD.

4. > Diversion is built on top of distributed storage and databases, accessible via REST API, and runs on serverless cloud infrastructure

What!?!?!? That is NOT a selling point....all that for a VCS?

You're literally taking everything that makes git great and saying that's what's wrong with git.

The only case you could make to sell this is maybe some sort of a high-end niche specific media heavy version control for storage intense users.

I would think that this is a college project but apparently you guys have a team size of 9 according to the website!!!

This is wild!

It kind of feels like an insult to Linus Torvalds.

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#102
Disclaimer: I am designing a Git alternative too.

Maybe "cloud native" will have a pull for game companies, but I am not so sure. I think a lot of studios would want to self-host.

"Git compatible" is an interesting phrase; does Diversion use the same type of backing store? If so, I am not so sure it will handle large files as well as hoped.

I had to solve this problem myself, and I did, but it required a different storage design.

Can it handle binary files? Is there a plan for doing so beyond "commit the entire file every time" or "use xdelta"?

I think this is how fourth gen version control systems will be defined. Game studios have a lot of binary assets, so this will be important.

All in all, I could see a product like this succeeding, but I think taking VC money was a mistake because there may not be enough space in the market for a company that has to keep growing to satisfy investors. I am taking zero VC, and that will allow me to make money on as few as three clients.

Anyway, I wish you both the best of luck!

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#103

You are not competing with Git, you are competing with Perforce. (Personally, I would never use a proprietary cloud-only offering for version control.)

> (Personally, I would never use a proprietary cloud-only offering for version control.)

yeah, I have no idea who would want to replace a free, open, well-debugged, featureful, ubiquitous vcs with a closed, immature SaaS offering...if your sourcecode is valuable, you don't let a YC startup gate-keep it (sorry)

git has terrible ergonomics for newcomers, but UI is exactly what the various git forges solve

for experienced devs, git issues get internalized like the issues with every other tool

a more realistic approach is the jujutsu stuff google is working on...works WITH git to create a better workflow

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#104
post #89

Earlier quoted context omitted.

So you were able to recover and did not lost a months work of data? Your story just doesn’t make sense. Come on.

Indeed you're right the work that was erased from BitBucket was restored from one of the employees that didn't yet pull, the post was edited accordingly.

Wouldn’t you still have been able to recover it even if everyone did pull, assuming GC had not run on everyone’s machine?

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#105
post #43

Earlier quoted context omitted.

He force pushed a diverged branch or something like that, and we only found out after a while. We were eventually able to recover because someone didn't pull. But it was not a fun experience :D

So multiple people did a git reset --hard origin/master and nobody complained or checked what and why this was done? That's not "one data scientist with the wrong command" but the whole team that fucked up hard IMHO.

I think you just sold their pitch with this comment... I, like many many people here, have done quite a bit of product design. What do you call it when a bunch of people use your product, and it breaks for several of them? That generally indicates your product is weak, or has a very rough UI.

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#106

Disclaimer: I am designing a Git alternative too. Maybe "cloud native" will have a pull for game companies, but I am not so sure. I think a lot of studios would want to self-host. "Git compatible" is an interesting phrase; does Diversion use the same type of backing store? If so, I am not so sure it will handle large files as well as hoped. I had to solve this problem myself, and I did, but it required a different st…

Thanks, good luck to you too! Would love to check it out! Diversion has totally different storage, that handles binary files with no issues, but same concepts as git - branches, commits and tags. It has a Git sync feature that allows to sync commits between Git and Diversion repos. Kudos on bootstrapping the product, it's definitely not easy! Version control is much harder than it seems, you've probably found out already :)

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#107
post #81
post #43

Earlier quoted context omitted.

He force pushed a diverged branch or something like that, and we only found out after a while. We were eventually able to recover because someone didn't pull. But it was not a fun experience :D

For your information you can use the reflog command to find the previous head commit and restore your branch. It takes 10 minutes and then you learn to disable force pushing on the main branch.

I find it funny how many comments in this angry rebuttal section actually endorse a Git replacement.

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#108

As others have mentioned I believe you underestimate the security requirements (often physical) imposed on game studios. Running P4 (and using the often publisher mandated tape backups) is the least of your problems in such an environment. If diversion were to succeed it would need a huge security team because it would represent far too tempting a target. Games stuff inspires a level of attack which normal businesses…

Thanks for the feedback! Totally true, I was surprised by how much emphasis on security there is in game studios. They are moving to cloud however, and we're hoping that a private cloud solution (Diversion running on their cloud account) would satisfy the requirements, at least a few years from now as cloud usage grows. Security is definitely going to be super important for us, in any case.

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#109
post #86

Earlier quoted context omitted.

>> a data scientist accidentally destroyed a month’s work of his team > This is mostly a configuration issue git apologism :) (FWIW I do agree with the rest of your comment, and I hope you forgive the slight joke. Product users, for any product are fallible humans. That might be fallible in accidentally deleting, or it might be fallible in forgetting to turn on the safety settings.) Very seriously, something like thi…

The issue with a lot of freedom and unopinionated tools is always going to be the multitude of ways to fuck up. On the flip-side, you may not like what choices are made if you’re forced to use it in a certain way. We enforce a strict pull-request squish commit with four eyes approval only. You can’t force push, you can’t rebase, you can’t not squish or whatever else you’d want to do. But we don’t pretend that is the…

> But again, what if the greater community decided that rebase was better than squash commit? Then we wouldn’t like Git, and I’m sure the rebase crowd feels the same way. The result would likely leave us with two Gits.

Meh, this is overrated. We'd end up with 2 Gits, and over time just one fork would probably take over, based on marketing, PR, dev team activity, etc. The second one would probably still be around but used by only a minor part of the community.

Just because a thing has on paper many forks, does not mean those forks are equal. In fact, a situation with many major forks rarely survives the long term. See Jenkins vs Hudson, Firefox vs Iceweasel, etc. Most people will congregate towards one of the forks and that's it.

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#110
As this is a startup the competitors are GitHub, Bitbucket, GitLab etc. and not the underlying technology. That is a mean to a goal, making money or most probably a lucrative exit.

> [git] was built for [...] much smaller projects,

It was built for the Linux kernel. There are larger projects than that but how many? Of course if you manage to make them switch to Diversion and get paid for that you could be well off even with a handful of customers.

About technical matters, as a company I'd be very at unease to have all my code only in the cloud on somebody's else servers. At least with git there are dozens, hundreds, thousands of copies of any repository around the company. If GitHub or AWS close our accounts we can keep going on and move somewhere else.

Post reply on HN