I know that OpenAI has made computing deals with other companies, and as time goes on, the percentage of inference that they run their models on will shift, but I doubt that much, if any, of that has moved from Microsoft Azure data centers yet, so that's not a reason for difference in model performance.
With that said, Microsoft has a different level of responsibility, both to its customers and to its stakeholders, to provide safety than OpenAI or any other frontier provider. That's not a criticism of OpenAI or Anthropic or anyone else, who I believe are all trying their best to provide safe usage. (Well, other than xAI and Grok, for which the lack of safety is a feature, not a bug.)
The risk to Microsoft of getting this wrong is simply higher than it is for other companies, and what's why they have a strong focus on Responsible AI (RAI) [1]. I don't know the details, but I have to assume there's a layer of RAI processing on models through Azure OpenAI that's not there for just using OpenAI models directly through the OpenAI API. That layer is valuable for the companies who choose to run their inference through Azure, who also want to maximize safety.
I wonder if that's where some of the observed changes are coming from. I hope the commenter posts their proof for further inspection. It would help everyone.
The fact that most of your Git commands are local-only is an artifact of how Git works, but I expect that ~100% of the time, you have an internet connection, so the fact that Grace needs to be connected to the cloud just isn't a thing I worry about.
I'm not writing a new VCS based on the 0.00000001% "but I'm on an airplane without WiFi" case.
There's ~0% reason in 2024 to build software for offline use cases, and even less reason in 2026 and 2028. I'm happy to cede that to Git if you really need it.
As an industry, we fetishize offline for version control only because Git sort-of does that. Again, it doesn't really... you still have to push to do real work with your team, but we need to stop pretending that's a hard requirement. It's totally not, it's just a "feature" of Git that gets in our way today more than it helps us.
> Also I once had a case of working on an air-gapped network.
Coming from Microsoft, and being familiar with the air-gapped Azure instances for government, I designed Grace to be able to run on those Azure clouds. In other words, all of the PaaS services that Grace would use on Azure are present in those clouds.
Even the air-gapped world isn't "offline", it's totally networked, just on a network that's not connected to the Internet.
I haven't specifically looked at similar AWS instances, but I have to believe it's possible there, too.
> Any plans to assimilate the build system as well?
No plans, not at all.
One of the design questions I've had in mind the entire time I've worked on Grace is: "What belongs to Git, and what belongs to GitHub?" (or GitLab or Azure DevOps or etc.).
I'm interested in completely replacing Git, but being very selective about pulling anything into the version control level that really belongs at the hoster level.
The only big thing I blurred the lines for is the including of Owner and Organization entities, to make multitenancy easier to support. My implementations of Owner and Organization are super-thin, just really hooks so the hosters can connect them to their existing identity systems.
The big hosters already have massive CI/CD and build platforms. The Grace Server API - and Grace Server is just a modern, 2024-style ASP.NET Core Web API, with no special protocols - will give us the ability to create, for instance, GitHub Actions that take the place of the Git fetch action that we all use today in our pipelines.
I'm happy to let the product and engineering teams at the big hosters figure out how to integrate with Grace.
One of the problems that GitHub and GitLab are going to face in the coming years, as Git gets supplanted whatever wins, is that "Git" is in the company name. Those names are going to sound they like provide yesterday's tech, in a hurry.
It's totally cool. It's not a product yet, it's a one-person project so far. I'm not asking anyone for any money. I expect one day that it will be a product.
It's still an alpha (see the highlighted note towards the top of the readme). There are features I intend to ship in 1.0 that aren't even started.
And even if all goes as well as possible, it won't ship 1.0 until 2026 at the earliest, which means early adopters, and mass adoption not until 2027 or 2028.
If you're going after something as big as Git, it takes time. It would be irresponsible to not think about where computing will be in a few years vs. today as I work on it.
I'm a long-time C# dev who got into F# about five years ago. F# is so awesome, I hope that if Grace catches on, that more people will pay some attention to it.
I'm a Windows user (and former Windows network administrator). I only use Linux as a target for containers, and rarely use a Linux terminal, so I know I'm not the right person to understand what Linux users want and need. I was a Unix admin in the late '90's for a couple of years, it was a bad enough experience to make me not want to be back in that world ever again. It's all subjective, of course.
I am pretty decent at designing UI's, and I hope Grace will be a non-terrible GUI for you (and for me).
Not at the moment, and probably not for v1.0 unless that bubbles up as a huge blocker.
You could accomplish it with something like:
- Make the changes in your branch
- Make a new branch off of `main` and cherry-pick the changes you want from your branch into that new one
- Commit and promote from the new branch; at this point you can delete the new branch
- Auto-rebase will run and propose a good merge to your original branch, which would include the partial changes you now have both in `main` and in your branch.
I still have to write cherry-pick - not sure that I'll call it that - and promotion conflict processing using LLM's. But something like the above steps would do what you're asking without too much effort.
There's no way to tackle the entire surface area of 20 years of Git in one release. I'm sure we'll see workarounds like that in v1.0 and learn from them to improve 2.0 and 3.0.
> 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.
There's no way to build something with an intention as big as "replace Git" that won't invite knee-jerk reactions.
I know I'm building the thing that aligns with my creative and technical vision. That's all I can do. It will succeed or it won't, and the reactions from people who are already super-comfortable with the existing technology matter less than the reactions from people who only understand the basics of Git and are afraid of it. I'm building it for them (which includes me).
Not with something like GitHub Secret Scanning monitoring things, or we could imagine a local ML model automatically checking every save before it gets uploaded.
This is an easily-solved problem. And in case one slips through, versions are easy to delete in Grace.
Don't get hung up on what GPT-4 can do. That's irrelevant. Even Sam Altman calls GPT-4 "mildly embarrassing".
"Don't skate to where the puck is, skate to where the puck is going." In 2028, for instance, will GPT-7 (or whatever) be able to handle solving a merge conflict? I expect it will.
Devs already do this all the time. That's why GitHub has Secret Scanning. The need for that kind of service doesn't change if the VCS changes.
> temporary large files
Saves in Grace are ephemeral, so those files will be deleted when the save references are deleted. There is a repo-level setting for how long that is, current default is seven days, but we'll see what makes sense.
> The storage and networking demands for this would be enormous.
Fortunately, Azure Blob Storage and AWS S3 and Google Cloud Storage are effectively infinite compared to any requirements from a version control system.
I've only written the Azure Blob Storage implementation so far, but the idea is that Grace offloads all file upload/download traffic to those object storage services, using Azure SAS tokens [1] or AWS Presigned URL [2], etc.
"Cloud-native", to me, means "built to scale up well". I find that's the connotation that most people associate with it.
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.
And, in any team dev situation, you're not getting anywhere until you `git push`, and that requires an internet connection. Assuming ~100% connectivity for devs around the world, in the late 2020's, is the right assumption to make. If offline is a hard requirement, Git isn't going anywhere.
> through non-http transports like mail
yeah, I'm not building a new VCS for that 0.0000001% case.
Popularity does not equal quality.