Live data from Hacker News

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

news.ycombinator.com

71–80 of 440 posts

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

#71

I'm having a hard time imagining positioning here. Can you explain further how Diversion differs from DVC, Git and when using Diversion makes sense over other use cases. The GTM is slightly confusing to me (also yes - Git is hard - you cannot teach data scientists this. It'll take months). Also agreed git is terrible right now for version-controlling workflows in AI (I have a fairly large .gitignore file with S3-host…

The vast majority of version control system uses are not distributed, even if the system itself is (GitHub and BitBucket were born to essentially make Git centralized). An example use case is game studios having repos with very large histories (hundreds of GiBs and more) where the tip is significantly smaller. Having the entire repo history on your local machine might be infeasible, and usually unnecessary. Being able to get just the tip and get the rest via API calls solves this. Having things continuously synced has other benefits like preventing conflicts at the time they happen on files that are hard for conflict resolution like game scene files, graphics etc.

AI workflows are definitely a use case we are looking at in the near future. What types of files are you hosting on S3?

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

#72
post #63

Earlier quoted context omitted.

So the work wasn’t actually destroyed, and you were able to recover it. So all the people pointing out how implausible that part of your pitch was were right, and you were in fact just lying.

That's really not the main point of the post, but you're right I should have been more precise. Edit: updated in the top text now!

I think the point being made is that you spent a lot of your opening post talking Git, and lead with that bit, rather than with Diversion. What makes Diversion different is added in the end, after you've spent time trying to convince Git fans that their current tooling isn't good. Worse, the examples you listed of why Git is bad is more reflective of configuration and processes than Git itself.

This is ultimately a very weak pitching strategy. The first thing you convey to your potential users is insecurity--an insecurity that people won't choose your product over Git. And it's hard to want to buy something from someone that isn't secure enough about their product to pitch the product first, and answer questions/make comparisons after, as a form of clarification.

Alternatively, instead of doing a comparison to Git, you could start with a list of "have you experienced these Git issues? . Here's how Diversion improves on Git in this regard." In this case you're actually solving people's problems, rather than looking like you're grasping at straws to complain about Git and justify an alternative.

FWIW, I personally have 0 interest in a cloud-first version control. I like the cloud as a form of backup and syncing with team members, but I ultimately want a version control that works as well offline as it does online, and prioritizes the local experience.

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

#73
post #26
post #24

Earlier quoted context omitted.

Nice! We didn't even know about that. Thanks!

Yeah, collaboration in music and video production is pretty unsolved. It often involves sharing huge files in GDrive/Dropbox, lots of project_latest_january_version_3_final_modified_updated.zip etc

Final_version_4_really_final, we've all been there :D

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

#76
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.

And the tool made a screwup that hard not only possible, but very difficult for the victims to recover from.

Doesn't say a lot for git's usability.

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

#77
post #4

Is my company's private information e.g. source code kept end-to-end encrypted?

Good question! End-to-end encryption would mean that you can't run cloud CI or merge conflicts in the cloud and other features. To my knowledge none of existing VCS solutions are end-to-end encrypted (I might be wrong though!)

We might add end-to-end encryption in the future (disabling some capabilities), if there's demand for it.

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

#78
post #63

Earlier quoted context omitted.

So the work wasn’t actually destroyed, and you were able to recover it. So all the people pointing out how implausible that part of your pitch was were right, and you were in fact just lying.

That's really not the main point of the post, but you're right I should have been more precise. Edit: updated in the top text now!

[flagged]

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

#79
Having worked with SVN a decade ago and Perforce more recently: that part of the market is waiting to be disrupted. I'm a little unsure whether it was actual technical reasons (vs cultural) that kept git out of those use cases. Many devs were working with git locally and using git-svn or git-p4 to interact with the local repo. Best of luck!

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

#80
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.

> but the whole team that fucked up hard IMHO.

Multiple individuals with similar problems would tend to imply systematic inadequate training. Or the enterprise concerned adopting an inappropriately complex system for its intended userbase.

Post reply on HN