Live data from Hacker News

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

news.ycombinator.com

81–90 of 440 posts

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

#81
post #43

Earlier quoted context omitted.

Even a force push doesn't destroy the reflog or runs the GC server-side. I wonder how you can accidentally loose data with Git. I've seen lot's of people not being able to find it, but really destroying it is hard.

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.

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

#82

Your core feature is live updates of changes. That is actually a nightmare. I don't want live updates. It will be a mess. If you really want to do cloud. Use git.

Thanks for the feedback! If you're on a separate branch it doesn't update from main automatically. We're also thinking to make live update of main optional as well, this is actually one of the most debated features internally. Apparently some users like it and some really don't.

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

#83
This looks really cool! Well done! Definitely looking into this for my startup. Currently we use a mix of Git and Perforce, but Perforce is a pain to maintain and very difficult for the non-coder on our team to work with for art assets.

When we started I looked at Plastic SCM (owned by Unity)—looks like it targets a similar use case to Diversion. I honestly can’t remember why I moved away from it—I think it was the lack of polish and capabilities vs git/GitHub. I’m curious how you compare yourselves to them.

I really like the bidirectional git sync you mention so I can try it gradually. Pricing seems good.

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

#84

Earlier quoted context omitted.

I also always wonder in cases like this if the person just didn’t know about reflog. You _really_ have to try to fuck up hard enough that everything is gone, it just might require even more arcane commands than what got you into a mess.

I've used reflog many times, but I'm not sure if this: > You _really_ have to try to fuck up hard enough that everything is gone ...is still true when using git-lfs, which seems common when using large data sets.

I believe it works the same. The large files are not immediately pruned.

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

#85
post #25
post #11

Earlier quoted context omitted.

Totally right, perforce is used by almost all large game studios. But it's painful to use for smaller studios and indie devs - it requires managing your own server with configuration, backups, networking etc. It's also not great for cloud based workflows and remote work, and super expensive with rigid licensing.

Most of the time we need to host our own servers for licensing issues, you might need to consider a "on premises" option if you want to be an viable option for a lot of studios.

This sounds like a classic innovator's dilemma style division in the market.

The incumbents need to cater to existing customers with a need to host their own servers for licensing reasons; but this forbids them from using cloud native features in the core of their products.

There may well be space for a newcomer to make a cloud only product targeted at the subset of studios that have the legal ability to use the cloud. Instinctively, there may be some useful features around large files which are possible in the cloud but impractical in an on prem environment.

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

#86
post #16

I have not analyzed the full potentials and benefits of Diversion but I would not agree with the statements you made about the Git. I think you should not focus on Git in your pitch. >> it was built for a very different world in 2005 (slow networks, much smaller projects, no cloud) Slow network: why is this a negative thing? If something is designed for a slow network then it should perform well in a fast network. Mu…

>> 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 “correct” way to use Git, we think it is, but who are we to tell you how to do you?

We take a similar approach to how we use Typescript. We have our own library of coding “grammar?” that you have to follow if you want to commit TS into our pipelines. Again, we have a certain way to do things and you have to follow them, but these ways might not work for anyone else, and we do sometimes alter them a little if there is a good reason to do so.

I don’t personally mind strict and opinionated software. I too think Git has far too many ways to fuck up, and that is far too easy to create a terrible work environment with JavaScript. It also takes a lot of initial effort to set rules up to make sure everyone works the same way. 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.

Though I guess with initiatives like the launch here, is two Gits. So… well.

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

#88
post #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 abl…

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

"Being able to get just the tip" is `git clone --depth 1`, isn't it?

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

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

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

#90
> a data scientist accidentally destroyed a month’s work of his team by using the wrong Git command (EDIT: we were eventually able to restore from a non-updated repo clone, after a few hours)

This is actually reads like a benefit of using Git. It's really really hard to lost something completely in Git, because reflogs, because there are multiple people on your team each has the same copy of the repo, etc.

Post reply on HN