Live data from Hacker News

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

news.ycombinator.com

181–190 of 440 posts

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

#181
post #177
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…

Git is bad for games and they should definitely compare them in their pitch if they want to capture that market.

No, it's not. LFS has improved over the years. Git is supported as a first class citizen in Unreal Engine 5 - alongside P4.

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

#182

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.

> doesn't destroy the reflog or runs the GC server-side. Git doesn't give you access to the server side reflog either. So it's of not much use if you don't control the server. As for losing data with Git, the easiest way to accomplish that is with data that hasn't been committed yet, a simple `git checkout` or `git reset --hard` can wipe out all your changes and even reflog won't keep record of that.

> As for losing data with Git, the easiest way to accomplish that is with data that hasn't been committed yet

Also Git has pretty awful behavior losing changes when one doesn't press "Save" in their IDE. Bad, bad Git.

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

#183

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…

> 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. Cloud native and self-hosting are not mutually exclusive.

They are in this case.

…and, frankly, they are in most cases. Most “cloud native” apps are designed to run on cloud services like VendorHere cloud storage, cloud functions, cloud containers, etc.

A vanishingly few of them are actually self hostable.

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

#185
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…

> When Micorosoft adopted Git for Windows, they faced this problem and solved it. On Windows. On Linux Git still doesn't scale well to very large repos. Before you say "but Linux uses git!", we're talking repos that are much bugger than Linux. Also the de facto large file "solution" is LFS, which is another half baked idea that doesn't really do the job. You sound like you're offended that Git isn't perfect because y…

>> When Micorosoft adopted Git for Windows, they faced this problem and solved it.

> On Windows. On Linux Git still doesn't scale well to very large repos.

All of Microsoft's solutions for git scaling have been cross-platform. Even VFS had a FUSE driver if you wanted it, but VFS is no longer Microsoft's recommended solution either, having moved on to things like sparse "cone" checkouts and commit-graphs, almost all of which is in mainline git today.

I also find it funny the complaint that git scales worse on Linux than Windows given how many Windows developers I know with file operation speed complaints on Windows that Linux doesn't have (and is a big reason to move to Windows Dev Drive given the chance, because somewhat Linux-like file performance).

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

#187
post #177

Earlier quoted context omitted.

Git is bad for games and they should definitely compare them in their pitch if they want to capture that market.

No, it's not. LFS has improved over the years. Git is supported as a first class citizen in Unreal Engine 5 - alongside P4.

Good for developers using Unreal Engine 5 I guess. Fact remains that most game developers struggle with Git.

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

#188

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.

> doesn't destroy the reflog or runs the GC server-side. Git doesn't give you access to the server side reflog either. So it's of not much use if you don't control the server. As for losing data with Git, the easiest way to accomplish that is with data that hasn't been committed yet, a simple `git checkout` or `git reset --hard` can wipe out all your changes and even reflog won't keep record of that.

A month of work for a whole team was never even committed or stashed let alone pushed? That is not a git problem.

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

#190
The world needs a git alternative. Anyone who has used mercurial at Google or Facebook knows the tooling could be much better.

As soon as you have 2-3 people committing to the same repo daily, git falls apart fast. The biggest difficulties with git are merging and branch rebasing. If git could do rebases better, I would suspect software development teams to universally move about 20% faster.

Post reply on HN