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
Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
81–90 of 440 posts
Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
#82Your 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.
Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
#83When 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
#84Earlier 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.
Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
#85Earlier 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.
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
#86I 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…
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
#87Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
#88I'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…
"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
#89Earlier 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.
Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
#90This 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.