[joepie91_]

> Git, or any file-server based software, is not built to scale up well in today's world. Large Git hosters have to invest entire teams to manage their file servers and their Git front-end systems to create a web-scale service on top of a file-server based piece of software. I'm just skipping to the part where you don't need that anymore because Azure / GCP / AWS PaaS services already handle that.

This doesn't really make any sense. Most people are not "large Git hosters" (and so for them there is no functional difference between "outsourcing Git hosting" and "outsourcing to a Grace hoster that is outsourcing file handling", and even for those who are large Git hosters, they're still going to need a team of sysadm- sorry, "cloud experts" to manage the AWS/Azure/whatever infrastructure.

What actual material benefit is being provided here? It seems to me like it just trades "administrating a standard hosting environment" in for "administrating a vendor-locked hosting environment".

[SBArbeit]

> This doesn't really make any sense. Most people are not "large Git hosters"

I do work for GitHub, so I do know what it takes.

Most people don't run their own Git servers, they use GitHub / GitLab / Azure DevOps / etc. and I intend to create something that's easy for those hosters to adopt.

Grace is also designed to be easily deployable to your local or virtual server environment using Kubernetes - and if you're large enough to want your own version control server, you're already running Kubernetes somewhere - so, party on if you want to do that, but I expect the number of organizations running their own version control servers to be low and shrinking over time.

And Git isn't going anywhere. If that's what you to run on your own server and client, I won't stop you.