SBArbeit

This SDK is widely trusted, but it carries significant technical debt:

    Performance risks
    Memory leaks
    Design flaws
    Maintainability issues

Avalonia. https://avaloniaui.net/platforms

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.

[1] https://www.microsoft.com/en-us/ai/responsible-ai

Everything about the title of this article is frightening.

You can see it deployed as a web site at https://bandysc.github.io/AvaloniaVisualBasic6/.

This is brilliant. Thanks for building it.

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.

Eh, I'm not really an Elvis fan...

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.

Not gonna make that same mistake for Grace.

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.

And .NET is so fast. No-brainer.

Thank you, I appreciate even the one data point.

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

Hi - can Grace support partial commits somehow?

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.

My bet is it will be forgotten in a year.

How much? ;-)

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.

Thank you. <3 I do ignore them.

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.

inadvertently committing secrets

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.

[1] https://learn.microsoft.com/en-us/azure/storage/common/stora... [2] https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareO...

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

It sounds like Linux is not a priority now?

The "probably Linux" line was when I was thinking of using .NET MAUI for the GUI, and they were considering adding Linux support. My bad, I need to change that.

.NET MAUI has decided not to do that, so I'm going to build the GUI with Avalonia, which does have Windows / MacOS / Android / iOS and Linux desktop support, as well as WASM support, all from the same code base.

If I weren't using a cross-platform GUI framework like Avalonia, I really might not bother with a Linux GUI, or at least deprioritize it; I expect most Linux devs will just use the CLI. I'm totally curious how much GUI usage there will be on Linux...

When I hear "cloud-native" I think "built to scale up well". As opposed to "built to run on file servers" which means "doesn't scale well at all".

Is that just me?

Also, [1]. I start by saying it's centralized. I'm proud of it. It's the right direction for moving version control forward. And modern use of Git isn't really distributed anyway; it's centralized. We don't push to production from our dev boxes.

[1] https://github.com/ScottArbeit/Grace/blob/main/docs/Frequent....

I think you're trying to fabricate problems where there are none.

No, I'm not. The problems with Git's UX are well-documented, and have spawned many projects over the last 10+ years trying to deliver "Git, but easier" or "Git, but better", so it's not just me who sees this.

I'm happy for you that you're comfortable with Git, or so indoctrinated to the workarounds required to use Git well that you're used to them. I believe it's time for something very different, and much easier to understand.

why do you think Git managed to become the world's de facto standard VCS

I think it was because Git has lightweight branches, and an ephemeral working directory, both of which made it nicer to use than the older, slower, centralized VCS's. I've kept both of those features in Grace.

I also think it was because of GitHub wrapping a lightweight social network around Git and popularizing it, at the same moment that shared open-source dev really started to catch on as an idea. Without GitHub, Git wouldn't have won.

I do not think it was because Git is easy to use, overall. Again, maybe 20% of devs really get it, and the rest don't and just hope nothing bad happens. It was better in some important axes, and we've all paid the bad-UX tax to get those better parts, but 2005 was a long time ago, with a very different set of network and hardware conditions, and we can do better.

^ this

History will be riddled with invalid state: Code that won't even compile, code that compiles but just had something important deleted without yet being replaced, etc.

No, it won't.

Saves are ephemeral; they're for your personal use to look back at the changes you've made recently, to enable a time-limited file-level undo, and to help you get back into flow after an interruption by being able to review what you were thinking and working on. Saves will be automatically deleted after a repository-level settable length of time, I'm thinking 7 days by default, but we'll see what makes sense.

Checkpoints are also ephemeral, they'll just have a longer life before getting deleted. They're for your reference, to help you keep track of your work, or keep track of an interesting version, or whatever you want to use them for. Or don't. Up to you. I don't imagine caring, for instance, what versions you checkpointed nine months ago.

This eliminates the "squash vs. no squash" debate. The only references that get to `main` are promotions. Nothing to squash.

All of this makes version control more ambient, more something that just happens in the background, effortlessly. Once you try it, it's really nice. Obviously, I've been the first beneficiary of it.

I wouldn't want to have to explicitly "push" changes to my OneDrive files, and in the same way, I don't want to have to explicitly "push" changes on my own branch anywhere, that should just work.

In Git these mistakes are more easily avoided as you are deliberate about what you commit and what stays local.

And yet GitHub has built an entire security feature - Secret Scanning - because developers do not easily avoid checking in secrets.

We have to face the fact that Git not being able to delete versions easily is a bug, not a feature, and that we do indeed sometimes need to delete versions from a repo. And so we've built a set of workarounds for Git to prevent pushes from succeeding when secrets have already been committed locally. It's not ideal.

Grace will enable a combination of hoster-level Secret Scanning with a native ability to delete a version that you don't want. Imagine that you accidentally save a secret, it ends up in your personal branch as a Save reference, Secret Scanning catches it and prompts you about it: "A secret was detected. Should I delete that version for you?"

No rewriting, no "hey Copilot how do I fix my repo after I committed a secret?", just one click and it's gone.

This is a mixed bag to me, some of the features sound very cool. I like automatic pulling, doing away with stashing, splitting commits into checkpoints and merges, optional locking and supporting large binary files makes it super adaptable to non-programming workloads.

Thank you, I really am trying to write something that meets the needs of developers in the late 2020's.

I don't agree with replacing forking with branching because forking is not only done to contribute to the mainline project.

That's an interesting point.

I'll use "GitHub" below as a stand-in for "Git hoster", but they invented the fork, so, you know...

I start with the idea that forks are not a Git feature; they're a GitHub feature. They're bolted on to Git to enable open-source dev in lieu of opening up the main project to write access from everyone. You write to your own fork, which you have write access to, and then ask someone with write access on the main project (through a PR, usually, also a GitHub feature) to take your contribution and write it to the main project.

All of this is yet-another workaround that we're used to because of Git, but that doesn't mean that it's not a workaround, or that it's the best way to do it.

My design intent with personal branches instead of forks is to say: if you want to make a copy and go forth and work on it totally separately from the main project, cool, go ahead. But if you want to contribute to an open-source project, or have your own tweaks on it but still keep up-to-date with `main`, well, I'm writing a whole new VCS, let's rethink this part. Let's acknowledge that there's an important use case that forks have been the answer to so far, but that we can deliver using personal branches. Authorization in Grace won't just be at the repo-level; it will be at the branch level, too.

So you'll be able to create personal branches that you can write to, even if you can't write to `main` on an open-source project. And you'll be able to create PR's and have that code promoted by someone who does have access.

I also get the feeling that if Grace goes anywhere it's going to be commercialized. It's practically screaming paid service.

It's 100% meant to be easily adopted by the large hosters and offered as a new, web-scale version control system.

I expect Grace to be offered for free, the way that Git currently is, for personal accounts. The big hosters don't compete on the version control level, they compete on the services above that (project management, issues, CI/CD, security, etc.) and that shouldn't change whenever the thing that replaces Git catches on.

And it's also designed to meet the needs of enterprise customers. I've been an enterprise developer for much of my career, so I have some idea of what that requires. There's no way that a replacement for Git can be successful without addressing enterprise needs, and since we're building from scratch, we don't have to bolt that on anymore.

Because of that, I don't see a way to use venture capital to create "VCS vNext" to go after Git. The win for a new VCS is going to be adoption by the big hosters, not the creation of a startup that would have to also build All The Things (project management, issues, CI/CD, security, etc.) just to have a shot.

100% open-source, built in the open, no way around it as far as I can see.

Things like GitHub's Secret Scanning will still be there to check...

And if a secret ends up on your personal branch, you can delete the Save or Checkpoint or Commit and it'll disappear; no "rewrite history". Deleting versions is a native, expected use case in Grace.

Git not being able to delete versions is a problem that's so bad that we've had to build massive systems (i.e. Secret Scanning) as a workaround. Grace, being built now, takes it for granted that versions need to disappear sometimes.

In Grace, saves and checkpoints and, like Git, branches themselves, are ephemeral, they're meant to be created and deleted. Saves and checkpoints will be deleted automatically, with repo-level timeout settings.

I think we just need something like Git with:

There have been lots of projects over the last 10+ years that have been riffs on "It's Git, but <better in this way>", but none of them have really caught on beyond a small, admittedly passionate group.

I believe that's because once you go through the pain of learning Git, the idea of learning yet another distributed version control system or client seems so unappealing to most people that they'll never do it.

The truth is: if you're using GitHub or GitLab or some other hoster, you're already doing centralized version control; you're just doing it with a confusing distributed version control UX. I'm just trying to skip to the part where we just admit it and call it centralized and build something that makes that experience awesome.

When small trends change quickly - like, jQuery -> Ember -> Aurelia -> Angular -> React - the differences between them can be small.

When major trends change slowly, over decades - like relational -> map-reduce -> key-value -> document db -> graph db - the differences between them are usually much greater, and even if an older product adopts some piece of doing it the new way (think, SQL Server supports JSON storage well enough, but really you want to use a Document DB for that) it's a bolt-on or it doesn't quite fit with the design intent of the system.

Replacing Git is one of those large trend changes, and I don't believe that any "Git, but <better>" product will ever make that change happen. I think it's time for something really different, and a pendulum swing back to centralized, but with modern, fast cloud-native features and infrastructure, ready for high-scale monorepos and large file storage and effectively infinite repo sizes is the way to go.

I don't think there's a good, not-confusing way to build a distributed version control system. Others disagree, that's cool, and there are other wonderful version control projects like Pijul [1] and jj [2] and JamHub [3] and others who are trying to make a better distributed VCS. I know some of the people working on those projects, they're awesome, they care about doing it well, and I wish them all the luck in the world.

Something will catch on and replace Git, soon. Grace is my offering to that.

[1] https://pijul.org/ [2] https://github.com/martinvonz/jj [3] https://jamhub.dev/

How does it handle merge conflicts?

I'll use a simple example, with one `main` branch and however many child branches, like most repos.

In Git, we merge to `main`. In effect, we take code from some other branch, and we shove it towards `main`, using a merge operation which sometimes results in code being created in `main` that's never existed in any other branch.

This seems... odd. Even if we're used to it, it's just weird. Why would we want something in `main` that's never existed anywhere else, that's never been on a developers machine before, that's never been tested locally? So we build CI/CD pipelines and automated testing to check that code that's never been seen anywhere else and hope it's good.

In Grace, changes move from `main` to the child branches through (auto-)rebase. There are no merges. The "merge" takes place during rebase, when changes from `main` are applied to the child branches.

A promotion in Grace takes an already-existing version that's been committed to a branch, and simply creates a new reference to that root directory version in `main` that doesn't change any code at all. It's a simple database insert, actually.

Branch-level control of reference types

Oh, hell yes. This is a great feature, actually. When `main` only allows Promotions and Tags, you're guaranteed that nothing gets to it without a promotion, which we can expect we'll have proper authorization controls for, and proper event-driven pre-checks with CI/CD, etc.

No accidental "oops I pushed a secret and now everyone has to deal with rewriting history". Even if you push a secret to your branch, you can delete that save or checkpoint or even commit immediately. No harm, no foul. And the hosters will have something like GitHub's Secret Scanning to make sure that stuff doesn't end up in `main`.

SignalR

Fortunately, you won't have to manage it. ;-) The hosters, like GitHub or GitLab, will manage it for you. Microsoft already has first-party services with hundreds of thousands of concurrent users on SignalR, I'm not worried about this at all.