Sure if you want to push, but only maybe 10% of my Git commands relate to pushing/internet related stuff. The majority of my work is local-only commands that can be run on an airplane without wifi. Git lets me defer the internet required stuff to a later time. Its not clear Grace will allow me to do that at all.
Also I once had a case of working on an air-gapped network. That was an interesting case that I'm not sure Grace would be suitable for at all? Granted that's super niche.
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.
I wrote about it more extensively here: https://beza1e1.tuxen.de/monorepo_vcs.html
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.
Not gonna make that same mistake for Grace.
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.
And .NET is so fast. No-brainer.
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).