> In Git, commit is an overloaded concept ... Grace simplifies this by breaking these usages out into their own gestures and events: ...
To me, now having two different commands which I need to distinguish means actually some mental overhead. I need to think about, is this really ready now, or only partially ready? Often I don't really know. I keep rebasing and editing my history of commits until I think they are in a good shape, and then I publish (make a PR).
grace promote seems easy to distinguish, if this is only intended for merges. Although I also don't see why it is such a problem to consider this also as a type of commit. Also, how are conflicts handled there? In Git, a commit always comes with a well defined state of the file tree, with one, or multiple parent commits (or also zero for the initial).
> Every save is uploaded, automatically
How does this handle files which are not yet tracked? Or all new files are automatically added? With Git, I always check first what files are added before I commit some new directory, to make sure I don't add files which don't belong into Git, like generated binaries or so.
> You can fix [the merge conflict] while you're in flow, and skip the conflict later.
To me, suddenly getting a merge conflict because of the background auto-rebase while working on some code sounds more like a distraction to get me out of the flow?
> Personal branches, not forks
So, you mean it's a centralized system? But does that mean, forks are not possible? Or when you fork, there are no good ways to work together anymore, e.g. merging branches from other forks?
> Grace will have a native GUI app for Windows, Mac, Android, and iOS. (And probably Linux.)
It sounds like Linux is not a priority now? This will turn off a lot of developers. I think for a new version control system, it makes more sense to have Linux as a priority, and Windows etc can come later.
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...
One data point: I'm a Linux user and I prefer GUIs for fiddly things like version control, although in some cases I end up using the terminal anyways because all the GUI options are terrible.
I use PyCharm and I also prefer the builtin Git GUI over the command line, at least when also working within PyCharm. I use PyCharm mostly on Linux and Mac.
Yeah always tracking and uploading everything seems nice but brings with it security concerns. For example, if I generate a secret key or store a private keyfile into the repo before remembering to gitignore... err I mean graceignore it, then that key gets uploaded to the cloud. Oops.
In Git these mistakes are more easily avoided as you are deliberate about what you commit and what stays local.
> 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.
It appears that this solves exactly no problems which I have, while introducing a slew of problems I don't have currently and am grateful not to.
I know this comment risks falling to the low-brow dismissal bucket, but it's hard for me to say anything more cogent than that. It all seems so obvious? Like, Kubernetes, your choice of cloud provider, "who works offline anyway"...
I got used to real-time version tracking when I was working on a book. The publisher insisted that the working files are kept in the Box folder (like a DropBox, or any other cloud-shmoud synchronized storage). This was... convenient and practical. This way of working is much better than the Git way if you work alone and produce dozens or hundreds of meaningful changes a day.
But at some point you have to publish. You have to make sure your state is correct to some level of certainty, and share it with other people. So you still need some kind of 'commit' thingie.
I think, Grace gets this both ways right. Personally, I just keep GitHub repos in a DropBox folder, but if Grace catches on, I might consider hoping in.
Thank you. One of the original, first-night-dreaming-about-it inspirations for Grace was the OneDrive sync client; since they rewrote it back in like 2018 or whatever it's been so rock-solid, and it's ambient.
I wanted that experience for version control; make as much happen in the background as possible, and make it fast when you need to interact with it.
OneDrive sync and "rock-solid" in the same sentence? I beg to differ.
Frequent conflicts due to non-synced files, the client crashing, randomly failing auth, files that are indicated to be recent and in sync but really aren't, no proper debuggability, no insight into why things don't work if they (frequently) don't. I could go on. OneDrive is a very bad thing to reference in this context.
I think probably the big difference is "if you work alone". You have to go to extra effort with Git because you need your changes to be understandable and usable by other people.
I dunno if this is the right thing for team based coding projects. I think we just need something like Git with:
* A saner CLI
* Proper support for large files
* Proper support for submodules
* Better conflict resolution
I think Pijul goes some way towards some of those, especially the last one, and maybe submodules.
I am also hopeful for Pijul. But yes, the "if you work alone" backfires for it too. If I work alone, I can adopt Pijul in my work easily, but I don't really want it. If I work within a group then I do want a better VCS, but I should convince the majority of people I work with to switch to the new thing, so essentially I can't switch to Pijul unless there is an undoubtfully good reason to do so. And incremental gains are not a good reason. A "saner" and "better" isn't enough.
On the other hand, we all work alone in between commits (in a broad sense of the term), so having a second tier of a version control, a personal tier, may be a gamechanger.
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.
Do you ever need to bisect regressions in a writing project? Do you need to maintain multiple releases and cherry pick patches across? Or does the latest version always supersede the previous? It seems like a far easier problem than what git is designed for.
If they're used by the software and aren't deterministically producible by the code, then I don't really understand how anyone could say that they don't belong.
Hi! Which one are you working on? (I created Grace.)
I'd love to chat... I've spoken to the creators of several other VCS's, it's a nice group of people. Hit me up on Twitter or whatever, I'd love to hear what motivated you, and what you're solving for.
You don't know about it because it is far behind Grace.
One of my motivations is hatred of Git, but unfortunately, I hate CMake more, so I wrote a build system first that I literally just released a month ago. [1]
So I am rightfully unknown to other VCS creators.
Also, I hate Git despite being one of the 20% that know 80%. I have done things with Git that no one should do. [2] [3]
Another of my motivations is vendor lock-in. Yes, Git is decentralized, but it doesn't include everything people want for repos, such as issue trackers. These things are what GitHub, GitLab, and others use to lock users in. Mine will follow Fossil and peovide everything, so users can switch providers easily.
So I strongly disagree with your cloud-first design.
My third motivation is binary files. Why don't we track them better? I mean, yeah, xdelta is cool, but we could do so much better.
I want to track changes to binary files the way we do with text. [1]
For example, if you have a PNG texture, my VCS will track changes at the pixel level. If you have a Blender file, it will track changes at the item level, from meshes to materials and vertices, and everything in-between.
Yes, it will be a lot of manual work to implement each file type, but that's how I plan to make money.
[1]: Only files that use lossless compression, of course.
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.
I don't think uploading on save is a wonderful idea for many reasons mentioned here. I don't agree with replacing forking with branching because forking is not only done to contribute to the mainline project. I'm against stuffing AI where solves no problem.
I also get the feeling that if Grace goes anywhere it's going to be commercialized. It's practically screaming paid service.
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.
> 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.
> Things like GitHub's Secret Scanning will still be there to check...
When a DVCS is successful, there are many server software. For git, there is the official git daemon and its wrappers (gitolite...), but also many forges, some of them having many local instances (Giltab, Gitea...). Grace should not depend on an optional (and error prone) feature of the server.
> Git not being able to delete versions
I don't understand. There is no concept of "version" in Git. You can delete commits, references and objects. For instance, you can delete/update a commit in your local branch. The old commit is still reachable, but you can run the garbage collector to delete it. You can also force a push that delete commits on a distant repository.
As far as I know, the problem with deleting published secrets on public forges is that as soon as anything is published bots will copy it. And some of these bots are ill intentioned.
My guess is that it's going to end up a clusterfuck of everything and a kitchen sink built on ill-defined murky concepts with an easy UI bolted on top. Just the opposite of git.
You don't seem to care much about simplicity, you care about shiny features.
Could you update the project's README.md to say right on the first paragraph objectively what Grace is and what are it's main selling point, followed by a example of Grace's happy path?
The document as it stands just presents a list of vague buzzwords that are irrelevant for a VCS (cloud-native?!) and even after scrolling half way through the doc the reader still has no good clue what he is reading about, let alone why they should bother with Grace.
A paragraph with an objective description would be helpful, followed by a small example presenting Grace's happy path. All the marketingspeak just gets in the way.
Disagree. "cloud-native" to me sounds offputting. One of the main selling points for me of git over the likes of SVN is the capability to work offline, in restricted networks and through non-http transports like mail.
Whoa, the line "Every save is uploaded, automatically [by default]" needs to qualify the non-default options. Can a company policy demand that? I hope there is a protocol-level, client-side opt-out for that, otherwise this VCS will work for the company first, and the dev is an afterthought.
"Upload every keystroke" is a huge no, and is going to be abused by companies looking for some performance metric to apply to devs (cloud IDEs are going to lead to that as well). Or things will revert to pre-git workflows where a huge number of files will remain open/changed until the final submit/push.
My workflow is to do the `grace checkpoint` equivalent and only make it public once it is presentable (and won't waste other peoples time when looking over or reviewing it). I never ever want these personal checkpoints/commits anywhere else. Mercurial/hg initially also had no easy way to have and clean up local-only commits, so for me and many others git it was.
> Whoa, the line "Every save is uploaded, automatically [by default]" needs to qualify the non-default options. Can a company policy demand that? I hope there is a protocol-level, client-side opt-out for that, otherwise this VCS will work for the company first, and the dev is an afterthought
I'm not so worried about the company. If they want every save uploaded, there are other ways to accomplish that, and they will have their upload. As a developer, I do not like "every save" saved because many editors trigger reformats on saves and such. Who cares about pre-reformatted code? That makes for junk history being pulled into VCS in a way that will eventually make the VCS data garbage. This is a feature that works for some workflows, but I suspect will be not so great for the team.
I don't think that works for the company or the dev. It turns history into a giant steaming pile of garbage instead of a series of meaningful changes. 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.
> Not a problem I thought I needed to solve, but okay. Also this means I can't easily run it locally?
I would add that this sounds like a big step backwards, as it conveys the idea of a svn-like version control system designed for the service provider to hold your project hostage.
> I already understand git, so does everyone on my team, and everyone that interviews...
Really? Because every team I've ever met could use git but the moment anything left the golden path they had to either 1. delete everything, reclone, and manually fix things up, or 2. turn to the one greybeard who actually did understand git. Either your team is the 99th percentile, or your definition of "understand" is rather generous.
It's not meant to be a local version control system, unless you enjoy running local Kubernetes clusters (which I have to do, but don't enjoy).
It's meant to be the next big thing in version control - no reason not to go for it - which means that it would have to be picked up by the major source control hosters, and since I know what it takes for GitHub to run its infrastructure, I know that it makes much more sense to build something new on PaaS services, not on file servers. Not anymore.
> I already understand git, so does everyone on my team, and everyone that interviews...
Yeah, but do they? That's not my experience, and it's not the experience of most people I talk to about it. Most devs I've asked about it understand the basics of how to use Git, but they're still afraid of it if anything goes wrong. My guess is that the ratio is 20% deeply understand it, and 80% only know what they need to and hope nothing bad happens.
Maybe your team are all a bunch of reflog wizards... that's awesome. And uncommon.
And I almost always get laughs and head nods when I talk about the problems with Git's UX.
> Is large files the main problem this solves?
No, but it's a big problem for gaming companies, who are mostly stuck on Perforce. And Git can't handle them well without the bolted-on LFS. And with the rise in monorepos, more and more enterprises want to be able to store more and bigger files than ever before.
> And maybe requires an internet connection?
Yes, absolutely, it does. So does Git if you expect to push anything anywhere. And if you happen to be doing dev using Azure or GCP or AWS you need one too.
Building something that would become popular in the late 2020's, and assuming that users will have solid Internet connections (don't forget satellite) is what makes sense. If you're still in a situation where you need offline VCS then, Git will still be there.
> Maybe this is for pair programming?
You could use it for that, but pair programming is not a direct design intent.
The design and motivations document is pretty long but doesn’t really describe the design. Things like which language you use aren’t the design, they’re more like design constraints and the environment in which the design happens.
The document about branching strategy [1] is closer to what I’d expect of a design doc.
But it avoids the hard problem of how live merges to the child branch work. What happens when a large refactoring automatically happens in the background while you’re in the middle of editing? In a fast-moving repo, it seems like new compile errors could spontaneously appear at any time, or tests could start breaking on their own. It seems like it would be frustrating to debug.
Hi - can Grace support partial commits somehow? Such as if I want to check in part of a file but not other parts? This is a key feature of Git for my workflows but doesn’t seem to be plausible at all if files are pushed up on save. Unless this would be part of “promote requests” only?
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.
Moin! Congratulations on what looks to be a great deal of work for a solo developer.
Whilst you might see some kickback here, I personally think it’s quite brave to take something like version control that has such a large established user base with git and say, I can do better.
Also nice to see this being written in .NET. It’s just so fast these days and multi-platform. If you’re looking for inspiration for the various clients, I recommend the open source BitWarden project. I’ve learnt a lot from that.
Why does the concept of a commit have to be broken into three distinct concepts; checkpoint, commit and promotion? Apart from communicating intent, what does the distinction buy me? There may be a good reason for having these baked into the VCS, but it's not clear from the readme, so I think most git users will just get the impression that grace imposes a particular workflow and forces the user to perform extra administrative tasks.
A better question is: why does git only have one gesture for it, when devs clearly use it to mean different things already?
All of the squash vs. no squash debate, which may or may not influence the way you use `git commit`, is a workaround - that we've forgotten is a workaround - for the fact that Git has only one way to say it.
Another way to say that: one of Git's leaky abstractions - the "commit" - forces us to use workarounds to make sense of it and how it's used and where it should be tracked and shouldn't be tracked.
Grace just decomposes those separate use cases into their own gestures to make it easier for you to track your own work in your own branch. If you want to see all of the references in your branch, `grace refs`. If you only want to see the checkpoints and commits - i.e. you want to see the versions that you explicitly marked as interesting for one reason or another, you have `grace checkpoints` and `grace commits`.
Promotions are what Grace uses instead of merges to move code from a child branch to a parent branch. We sometimes call merges "commits" in Git, and, again, leaky abstraction and overloaded term.
> so I think most git users will just get the impression that grace imposes a particular workflow and forces the user to perform extra administrative tasks
A short intro to Grace - like 15 minutes - will change that impression, I hope. Most of Grace's workflow will be the same as Git, some of it will be different, and that's OK. New tools bring new ways of working, and that's a good thing, especially when looking at Git's UX.
I don't see a venture-driven way to be the thing that replaces Git. And I don't see a way to replace Git without being developing in the open. So, no GraceHub.
Any plans to assimilate the build system as well? Grace seems to handle large files and can deploy stuff to developers and servers. Why have a separate system for deploying build artifacts to developers and servers then? By integrating with the build system a VCS knows which files are build artifacts and which are sources.
> 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.
Obviously, the intention is to get there. It's still an alpha, and it's not ready to be trusted for real yet. (And that's OK.) There are a lot of features yet to be written.
With that said, it does do the basics well: save/checkpoint/commit/promote/tag, diff, status, rebase, list refs, ls for local version, ls for server version(s), etc. And it's fast. Still much more to do.
Funny story: At the beginning I was using both Git and Grace at the same time (a .git directory next to a .grace directory to drive them) on the source code. Then I worked on auto-rebase, and had a bug that deleted some of my source files . I was able to revert from Git, of course, but after that I decided to do my testing in other directories.
Many people before me have already pointed out many of the pain points of this project, but I'd like to ask you a few more things.
I'd like to start by congratulating though, this is no small feat!
As I understand it, this project requires an online connection to a hosted service. Said service is complex/heavy enough that it requires a k8s cluster or similar to run on, with databases, object storage, queues ecc..
Many already pointed out the unnecessary complexity, but the first thing i think of is:
> I'm never going to use this for my projects.
As in: My laptop is full of dozens, maybe hundreds of started/ongoing/stalled/failed/abandoned projects, Only a fraction of those ever leave my machine.
I can start a project with a local git repo as easily as one folder and one command, and have peace of mind knowing that i can still record any change i make and archive the important stuff if it ever takes off.
What about checking out other people's work? To contribute now i either need my own compute, or have access to someone else's compute.
This all screams expensive , and we haven't even mentioned AI.
As a few already said, uploading every keystroke seems madness to me. I may be not as good a developer as others, but I constantly do things that I would not want uploaded anywhere, sometimes use dirty hacks like hardcoding secrets for testing.
Let's not kid ourselves, we've all been in a position where the code was not well structured and we had to put in a magic string to make things work. Now the peace of mind that comes from the `watch` command made you upload everything, and maybe someone else's repo has already been auto-rebased onto it.
I get that you can not use the auto `watch` command, but it seems to me the whole project is centered around it.
Git is portable, I can share a folder/tarball and be done with it, this seems like google docs for coding, could I change provider if I wanted to? Backups now seem a fairly complicated ordeal.
As a side note, I've worked for one large national telco, I couldn't believe the amount of times servers broke or the VPN/Firewall/Wifi/network fairies had a bad day.
Having the entire VCS be online only leaves me with an unshakeable scary feeling.
The only environment in which I see this being a possibly reasonable choice is an enterprise one. Unless someone makes a bet and starts offering a hosted version this looks to me simply not it for one developer, too expensive/complicated for a small group, yet too new for a large organization.
And without the drive that comes from single developers that know how to use and trust it, the adoptions comes down to a bet made by some manager.
If i had to make one question, what is the future that you forsee for Grace? How would you spread its adoption without individual developers using it?
> I'd like to start by congratulating though, this is no small feat!
First of all, thank you. <3 It's been a journey, and it's only going faster. I'm more proud of Grace than anything I've ever written. And thanks for the long comment.
> Many people before me have already pointed out many of the pain points
Many people have reacted based on years of Git brainwashing, yes. :-) The people commenting here are usually the ones who deeply understand Git and wonder why other people don't and "what's the problem?" My experience in the last couple of years is that the reactions from that crowd have been mostly negative because they don't feel the pain that the other 80% or so of devs feel.
It's not unlike any other new technology. For example, SQL Server expert: "Why do we need a document database? SQL Server does what we need! This is a waste of time, just use SQL Server correctly!" Service Fabric expert: "Why do we need Kubernetes? Service Fabric does what we need! This is a waste of time, just use Service Fabric correct!" C++ expert: "Why to we need Rust? C++ does what we need! This is a waste of time, just use C++ correctly!"
It's like that.
Git has terrible UX, but it's the pain we know, and the workarounds that we're used to that we don't realize anymore are workarounds. Git is not the final word in version control, and we deserve better. There are other, much better ways to do things. Really.
> As a few already said, uploading every keystroke seems madness to me.
I never said "upload after every keystroke". Grace has no idea that you've typed anything - it's all user-mode, my days of writing Windows kernel-mode hooks are long since past. lol And I've never written a keystoke logger! eww...
It does use a file system watcher, so it knows when files in the directory you're tracking (i.e. the one with a .grace directory) have changed.
Right now, there's no explicit `grace add` like there's a `git add`. There's just a .graceignore file. I find Git's need for an explicit add gesture to be bad UX; again, it's UX that most have gotten used to, but that doesn't mean it's right. If enough people really want add to be explicit, we'll make it work but probably not make it the default behavior.
The only time auto-rebase happens is when the parent branch of your branch gets updated. We can all expect that, like GitHub has today with pre-receive hooks and Secret Scanning, that your files will be scanned for secrets and handled appropriately. The different for Grace is: deleting a version that you don't want is an expected, normal function, unlike rewriting Git history and hoping that everyone else sharing the repo does their fetches and rebases and whatever appropriately to remove the unwanted version.
> could I change provider if I wanted to?
I haven't written that level of import/export yet, but it'll have to exist at some point. Changing hosters is a rare, once-in-a-few-years-if-ever event for most organizations and most individuals, because it's not just about the code, it's about the CI/CD and packages and issues and PR's and project tracking.
> Backups now seem a fairly complicated ordeal.
Yes and no. I'll offer a backup in `git bundle` format, so that's simple. I have no intention of writing a live Git-to-Grace sync, the branching model is different enough that the corner cases would be hard to deal with.
On the server side, yes, like every other cloud-native system that uses more than one data service, backups will need to be coordinated. I've written a short paper on that [1].
> The only environment in which I see this being a possibly reasonable choice is an enterprise one.
Hard disagree. Enterprise is definitely a main target for Grace, but there's no replacing of Git without making life better for open-source devs as well, and Grace is meant for them/us. Personal branches on open-source projects, not forks, plus auto-rebase that keeps your personal branch up-to-date with `main` instead of walking up to a fork after weeks or months and seeing `234 commits behind` and declaring bankruptcy... until you actually use it, it might be hard to see how nice auto-rebase is, but, really, it changes how you feel about how clunky and manual and disconnected Git is.
Giving developers a different, much better UX is enough reason for open-source to adopt it, but when you see how fluid and connected it becomes to work together in open-source with Grace I expect it'll catch on.
> what is the future that you forsee for Grace? How would you spread its adoption without individual developers using it?
Short version:
Git is reaching it's EOL, for a few reasons. Grace is intended to be ready to meet the actual needs of developers in the late 2020's, not the mid-2000's like Git. Individual developers will use it. And the UX is so much better once you try it that it won't be a hard sell for most.
Longer version:
Git, as used today by most everyone, is a centralized version control system, that we access through a confusing distributed version control UX. Unless you push to production from your dev box, you're only shipping code by running `git push` and seeing that code run through some centralized CI/CD pipelines. This is one indication that the use case for Git, and the design of Git, have diverged enough to look like it's time for something new to come.
We all have to come to terms with the fact that we've found Git's fundamental design limits. As monorepos have come into fashion - and if we do nothing else in this industry, we follow fashion trends - we're seeing more and more that the only way to do large monorepos well is to use `git scalar` and partial clones so we don't clog our machines and Git servers with unnecessary traffic.
Once you're using `git scalar`, you're explicitly using Git as a centralized version control system, to run a repo that's centralized on a hoster, and the size of those repos forces GitHub and GitLab etc. to constantly invest in how to scale up the server side to match customer demands. Don't forget, the hosters all run Git protocol, but how they store data behind that protocol is the secret sauce of taking a mid-2000's client/server thing like Git and making it web-scale, and the demands on that scaling are only going up.
So, we've broken the client-side contract of Git - Git has the full repo on every machine! - with partial clones, and at some point the only way to scale up the server side is to not use Git repos, and break them up into object storage (this is what Azure DevOps does). So... it's no longer Git on the client, and it's no longer Git on the server. Why are we clinging to this thing?
This is what it looks like when a technology has reached it's EOL, and it's time to find something new.
Individual developers will 100% be using it... we'll all have the same free accounts on GitHub or GitLab or whatever hoster we use, and when we start up projects, they'll just be in Grace repos at those hosters. The vast majority of developers don't care how their version control works, they just want it to work. Grace is so much easier to understand than Git, and few people care about how much is local and how much is cloud, as long as it works and it's fast.
No one will force you to use Grace for your individual projects, but at some point, after using Grace, I don't think you'll want to go back. If you want to keep using Git yourself, it's not going anywhere.
I find it amusing how attached to "local repos" some devs have become when we have everything else we do live in the cloud, or synced to the cloud, and it's not a big deal. Source control isn't a different category of thing that must be local. It's just a no-longer-relevant habit from Git.
Readit News
To me, now having two different commands which I need to distinguish means actually some mental overhead. I need to think about, is this really ready now, or only partially ready? Often I don't really know. I keep rebasing and editing my history of commits until I think they are in a good shape, and then I publish (make a PR).
grace promote seems easy to distinguish, if this is only intended for merges. Although I also don't see why it is such a problem to consider this also as a type of commit. Also, how are conflicts handled there? In Git, a commit always comes with a well defined state of the file tree, with one, or multiple parent commits (or also zero for the initial).
> Every save is uploaded, automatically
How does this handle files which are not yet tracked? Or all new files are automatically added? With Git, I always check first what files are added before I commit some new directory, to make sure I don't add files which don't belong into Git, like generated binaries or so.
> You can fix [the merge conflict] while you're in flow, and skip the conflict later.
To me, suddenly getting a merge conflict because of the background auto-rebase while working on some code sounds more like a distraction to get me out of the flow?
> Personal branches, not forks
So, you mean it's a centralized system? But does that mean, forks are not possible? Or when you fork, there are no good ways to work together anymore, e.g. merging branches from other forks?
> Grace will have a native GUI app for Windows, Mac, Android, and iOS. (And probably Linux.)
It sounds like Linux is not a priority now? This will turn off a lot of developers. I think for a new version control system, it makes more sense to have Linux as a priority, and Windows etc can come later.
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...
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.
I know this comment risks falling to the low-brow dismissal bucket, but it's hard for me to say anything more cogent than that. It all seems so obvious? Like, Kubernetes, your choice of cloud provider, "who works offline anyway"...
No thanks.
Deleted Comment
I got used to real-time version tracking when I was working on a book. The publisher insisted that the working files are kept in the Box folder (like a DropBox, or any other cloud-shmoud synchronized storage). This was... convenient and practical. This way of working is much better than the Git way if you work alone and produce dozens or hundreds of meaningful changes a day.
But at some point you have to publish. You have to make sure your state is correct to some level of certainty, and share it with other people. So you still need some kind of 'commit' thingie.
I think, Grace gets this both ways right. Personally, I just keep GitHub repos in a DropBox folder, but if Grace catches on, I might consider hoping in.
I wanted that experience for version control; make as much happen in the background as possible, and make it fast when you need to interact with it.
Frequent conflicts due to non-synced files, the client crashing, randomly failing auth, files that are indicated to be recent and in sync but really aren't, no proper debuggability, no insight into why things don't work if they (frequently) don't. I could go on. OneDrive is a very bad thing to reference in this context.
I dunno if this is the right thing for team based coding projects. I think we just need something like Git with:
* A saner CLI
* Proper support for large files
* Proper support for submodules
* Better conflict resolution
I think Pijul goes some way towards some of those, especially the last one, and maybe submodules.
On the other hand, we all work alone in between commits (in a broad sense of the term), so having a second tier of a version control, a personal tier, may be a gamechanger.
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/
The only two things mine might do better are large binary files (because I do think they belong in version control) and decentralization.
I'd love to chat... I've spoken to the creators of several other VCS's, it's a nice group of people. Hit me up on Twitter or whatever, I'd love to hear what motivated you, and what you're solving for.
One of my motivations is hatred of Git, but unfortunately, I hate CMake more, so I wrote a build system first that I literally just released a month ago. [1]
So I am rightfully unknown to other VCS creators.
Also, I hate Git despite being one of the 20% that know 80%. I have done things with Git that no one should do. [2] [3]
Another of my motivations is vendor lock-in. Yes, Git is decentralized, but it doesn't include everything people want for repos, such as issue trackers. These things are what GitHub, GitLab, and others use to lock users in. Mine will follow Fossil and peovide everything, so users can switch providers easily.
So I strongly disagree with your cloud-first design.
My third motivation is binary files. Why don't we track them better? I mean, yeah, xdelta is cool, but we could do so much better.
[1]: https://news.ycombinator.com/item?id=39904895
[2]: https://gavinhoward.com/2023/02/a-git-sin-re-signing-an-enti...
[3]: https://gavinhoward.com/2023/07/how-i-made-a-monorepo/
Alright you got me, I'm listening
I want to track changes to binary files the way we do with text. [1]
For example, if you have a PNG texture, my VCS will track changes at the pixel level. If you have a Blender file, it will track changes at the item level, from meshes to materials and vertices, and everything in-between.
Yes, it will be a lot of manual work to implement each file type, but that's how I plan to make money.
[1]: Only files that use lossless compression, of course.
I don't think uploading on save is a wonderful idea for many reasons mentioned here. I don't agree with replacing forking with branching because forking is not only done to contribute to the mainline project. I'm against stuffing AI where solves no problem.
I also get the feeling that if Grace goes anywhere it's going to be commercialized. It's practically screaming paid service.
This is an easily-solved problem. And in case one slips through, versions are easy to delete in Grace.
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.
People are going to end up with so many credentials stored where they shouldn't be from local testing.
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.
When a DVCS is successful, there are many server software. For git, there is the official git daemon and its wrappers (gitolite...), but also many forges, some of them having many local instances (Giltab, Gitea...). Grace should not depend on an optional (and error prone) feature of the server.
> Git not being able to delete versions
I don't understand. There is no concept of "version" in Git. You can delete commits, references and objects. For instance, you can delete/update a commit in your local branch. The old commit is still reachable, but you can run the garbage collector to delete it. You can also force a push that delete commits on a distant repository.
As far as I know, the problem with deleting published secrets on public forges is that as soon as anything is published bots will copy it. And some of these bots are ill intentioned.
My guess is that it's going to end up a clusterfuck of everything and a kitchen sink built on ill-defined murky concepts with an easy UI bolted on top. Just the opposite of git.
You don't seem to care much about simplicity, you care about shiny features.
Could you update the project's README.md to say right on the first paragraph objectively what Grace is and what are it's main selling point, followed by a example of Grace's happy path?
The document as it stands just presents a list of vague buzzwords that are irrelevant for a VCS (cloud-native?!) and even after scrolling half way through the doc the reader still has no good clue what he is reading about, let alone why they should bother with Grace.
A paragraph with an objective description would be helpful, followed by a small example presenting Grace's happy path. All the marketingspeak just gets in the way.
Disagree. "cloud-native" to me sounds offputting. One of the main selling points for me of git over the likes of SVN is the capability to work offline, in restricted networks and through non-http transports like mail.
"Upload every keystroke" is a huge no, and is going to be abused by companies looking for some performance metric to apply to devs (cloud IDEs are going to lead to that as well). Or things will revert to pre-git workflows where a huge number of files will remain open/changed until the final submit/push.
My workflow is to do the `grace checkpoint` equivalent and only make it public once it is presentable (and won't waste other peoples time when looking over or reviewing it). I never ever want these personal checkpoints/commits anywhere else. Mercurial/hg initially also had no easy way to have and clean up local-only commits, so for me and many others git it was.
I'm not so worried about the company. If they want every save uploaded, there are other ways to accomplish that, and they will have their upload. As a developer, I do not like "every save" saved because many editors trigger reformats on saves and such. Who cares about pre-reformatted code? That makes for junk history being pulled into VCS in a way that will eventually make the VCS data garbage. This is a feature that works for some workflows, but I suspect will be not so great for the team.
> cloud-native version control system.
Not a problem I thought I needed to solve, but okay. Also this means I can't easily run it locally?
> easy to use, easy to understand
I already understand git, so does everyone on my team, and everyone that interviews...
> And it's powerful, ready to handle large repositories and large file sizes.
Is large files the main problem this solves?
> Grace Server scales up by running on Kubernetes and massive PaaS services from large cloud providers.
Even when I was running Git servers for large companies this wasn't a problem I had ...
> Grace Client runs in the background, making it ambient, faster, and more valuable to your everyday work as a developer.
How is that more valuable?
> Grace connects you with others working in your repository, across the globe,
So like every revision control system?
> in real-time
So it behaves like Google Docs? And maybe requires an internet connection?
>, enabling new experiences and new ways of sharing.
Maybe this is for pair programming?
So I want to use grace if I want to pair program on large files?
I would add that this sounds like a big step backwards, as it conveys the idea of a svn-like version control system designed for the service provider to hold your project hostage.
> I already understand git, so does everyone on my team, and everyone that interviews...
Really? Because every team I've ever met could use git but the moment anything left the golden path they had to either 1. delete everything, reclone, and manually fix things up, or 2. turn to the one greybeard who actually did understand git. Either your team is the 99th percentile, or your definition of "understand" is rather generous.
It's not meant to be a local version control system, unless you enjoy running local Kubernetes clusters (which I have to do, but don't enjoy).
It's meant to be the next big thing in version control - no reason not to go for it - which means that it would have to be picked up by the major source control hosters, and since I know what it takes for GitHub to run its infrastructure, I know that it makes much more sense to build something new on PaaS services, not on file servers. Not anymore.
> I already understand git, so does everyone on my team, and everyone that interviews...
Yeah, but do they? That's not my experience, and it's not the experience of most people I talk to about it. Most devs I've asked about it understand the basics of how to use Git, but they're still afraid of it if anything goes wrong. My guess is that the ratio is 20% deeply understand it, and 80% only know what they need to and hope nothing bad happens.
Maybe your team are all a bunch of reflog wizards... that's awesome. And uncommon.
And I almost always get laughs and head nods when I talk about the problems with Git's UX.
> Is large files the main problem this solves?
No, but it's a big problem for gaming companies, who are mostly stuck on Perforce. And Git can't handle them well without the bolted-on LFS. And with the rise in monorepos, more and more enterprises want to be able to store more and bigger files than ever before.
> And maybe requires an internet connection?
Yes, absolutely, it does. So does Git if you expect to push anything anywhere. And if you happen to be doing dev using Azure or GCP or AWS you need one too.
Building something that would become popular in the late 2020's, and assuming that users will have solid Internet connections (don't forget satellite) is what makes sense. If you're still in a situation where you need offline VCS then, Git will still be there.
> Maybe this is for pair programming?
You could use it for that, but pair programming is not a direct design intent.
The document about branching strategy [1] is closer to what I’d expect of a design doc.
But it avoids the hard problem of how live merges to the child branch work. What happens when a large refactoring automatically happens in the background while you’re in the middle of editing? In a fast-moving repo, it seems like new compile errors could spontaneously appear at any time, or tests could start breaking on their own. It seems like it would be frustrating to debug.
[1] https://github.com/ScottArbeit/Grace/blob/main/docs/Branchin...
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.
Whilst you might see some kickback here, I personally think it’s quite brave to take something like version control that has such a large established user base with git and say, I can do better.
Also nice to see this being written in .NET. It’s just so fast these days and multi-platform. If you’re looking for inspiration for the various clients, I recommend the open source BitWarden project. I’ve learnt a lot from that.
All of the squash vs. no squash debate, which may or may not influence the way you use `git commit`, is a workaround - that we've forgotten is a workaround - for the fact that Git has only one way to say it.
Another way to say that: one of Git's leaky abstractions - the "commit" - forces us to use workarounds to make sense of it and how it's used and where it should be tracked and shouldn't be tracked.
Grace just decomposes those separate use cases into their own gestures to make it easier for you to track your own work in your own branch. If you want to see all of the references in your branch, `grace refs`. If you only want to see the checkpoints and commits - i.e. you want to see the versions that you explicitly marked as interesting for one reason or another, you have `grace checkpoints` and `grace commits`.
Promotions are what Grace uses instead of merges to move code from a child branch to a parent branch. We sometimes call merges "commits" in Git, and, again, leaky abstraction and overloaded term.
> so I think most git users will just get the impression that grace imposes a particular workflow and forces the user to perform extra administrative tasks
A short intro to Grace - like 15 minutes - will change that impression, I hope. Most of Grace's workflow will be the same as Git, some of it will be different, and that's OK. New tools bring new ways of working, and that's a good thing, especially when looking at Git's UX.
I've invested a lot of time into getting used to git. What are my gains from learning grace?
I don't see a venture-driven way to be the thing that replaces Git. And I don't see a way to replace Git without being developing in the open. So, no GraceHub.
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.
Obviously, the intention is to get there. It's still an alpha, and it's not ready to be trusted for real yet. (And that's OK.) There are a lot of features yet to be written.
With that said, it does do the basics well: save/checkpoint/commit/promote/tag, diff, status, rebase, list refs, ls for local version, ls for server version(s), etc. And it's fast. Still much more to do.
Funny story: At the beginning I was using both Git and Grace at the same time (a .git directory next to a .grace directory to drive them) on the source code. Then I worked on auto-rebase, and had a bug that deleted some of my source files . I was able to revert from Git, of course, but after that I decided to do my testing in other directories.
I'd like to start by congratulating though, this is no small feat!
As I understand it, this project requires an online connection to a hosted service. Said service is complex/heavy enough that it requires a k8s cluster or similar to run on, with databases, object storage, queues ecc.. Many already pointed out the unnecessary complexity, but the first thing i think of is: > I'm never going to use this for my projects.
As in: My laptop is full of dozens, maybe hundreds of started/ongoing/stalled/failed/abandoned projects, Only a fraction of those ever leave my machine.
I can start a project with a local git repo as easily as one folder and one command, and have peace of mind knowing that i can still record any change i make and archive the important stuff if it ever takes off.
What about checking out other people's work? To contribute now i either need my own compute, or have access to someone else's compute.
This all screams expensive , and we haven't even mentioned AI.
As a few already said, uploading every keystroke seems madness to me. I may be not as good a developer as others, but I constantly do things that I would not want uploaded anywhere, sometimes use dirty hacks like hardcoding secrets for testing. Let's not kid ourselves, we've all been in a position where the code was not well structured and we had to put in a magic string to make things work. Now the peace of mind that comes from the `watch` command made you upload everything, and maybe someone else's repo has already been auto-rebased onto it.
I get that you can not use the auto `watch` command, but it seems to me the whole project is centered around it.
Git is portable, I can share a folder/tarball and be done with it, this seems like google docs for coding, could I change provider if I wanted to? Backups now seem a fairly complicated ordeal.
As a side note, I've worked for one large national telco, I couldn't believe the amount of times servers broke or the VPN/Firewall/Wifi/network fairies had a bad day. Having the entire VCS be online only leaves me with an unshakeable scary feeling.
The only environment in which I see this being a possibly reasonable choice is an enterprise one. Unless someone makes a bet and starts offering a hosted version this looks to me simply not it for one developer, too expensive/complicated for a small group, yet too new for a large organization. And without the drive that comes from single developers that know how to use and trust it, the adoptions comes down to a bet made by some manager.
If i had to make one question, what is the future that you forsee for Grace? How would you spread its adoption without individual developers using it?
First of all, thank you. <3 It's been a journey, and it's only going faster. I'm more proud of Grace than anything I've ever written. And thanks for the long comment.
> Many people before me have already pointed out many of the pain points
Many people have reacted based on years of Git brainwashing, yes. :-) The people commenting here are usually the ones who deeply understand Git and wonder why other people don't and "what's the problem?" My experience in the last couple of years is that the reactions from that crowd have been mostly negative because they don't feel the pain that the other 80% or so of devs feel.
It's not unlike any other new technology. For example, SQL Server expert: "Why do we need a document database? SQL Server does what we need! This is a waste of time, just use SQL Server correctly!" Service Fabric expert: "Why do we need Kubernetes? Service Fabric does what we need! This is a waste of time, just use Service Fabric correct!" C++ expert: "Why to we need Rust? C++ does what we need! This is a waste of time, just use C++ correctly!"
It's like that.
Git has terrible UX, but it's the pain we know, and the workarounds that we're used to that we don't realize anymore are workarounds. Git is not the final word in version control, and we deserve better. There are other, much better ways to do things. Really.
> As a few already said, uploading every keystroke seems madness to me.
I never said "upload after every keystroke". Grace has no idea that you've typed anything - it's all user-mode, my days of writing Windows kernel-mode hooks are long since past. lol And I've never written a keystoke logger! eww...
It does use a file system watcher, so it knows when files in the directory you're tracking (i.e. the one with a .grace directory) have changed.
Right now, there's no explicit `grace add` like there's a `git add`. There's just a .graceignore file. I find Git's need for an explicit add gesture to be bad UX; again, it's UX that most have gotten used to, but that doesn't mean it's right. If enough people really want add to be explicit, we'll make it work but probably not make it the default behavior.
The only time auto-rebase happens is when the parent branch of your branch gets updated. We can all expect that, like GitHub has today with pre-receive hooks and Secret Scanning, that your files will be scanned for secrets and handled appropriately. The different for Grace is: deleting a version that you don't want is an expected, normal function, unlike rewriting Git history and hoping that everyone else sharing the repo does their fetches and rebases and whatever appropriately to remove the unwanted version.
> could I change provider if I wanted to?
I haven't written that level of import/export yet, but it'll have to exist at some point. Changing hosters is a rare, once-in-a-few-years-if-ever event for most organizations and most individuals, because it's not just about the code, it's about the CI/CD and packages and issues and PR's and project tracking.
> Backups now seem a fairly complicated ordeal.
Yes and no. I'll offer a backup in `git bundle` format, so that's simple. I have no intention of writing a live Git-to-Grace sync, the branching model is different enough that the corner cases would be hard to deal with.
On the server side, yes, like every other cloud-native system that uses more than one data service, backups will need to be coordinated. I've written a short paper on that [1].
> The only environment in which I see this being a possibly reasonable choice is an enterprise one.
Hard disagree. Enterprise is definitely a main target for Grace, but there's no replacing of Git without making life better for open-source devs as well, and Grace is meant for them/us. Personal branches on open-source projects, not forks, plus auto-rebase that keeps your personal branch up-to-date with `main` instead of walking up to a fork after weeks or months and seeing `234 commits behind` and declaring bankruptcy... until you actually use it, it might be hard to see how nice auto-rebase is, but, really, it changes how you feel about how clunky and manual and disconnected Git is.
Giving developers a different, much better UX is enough reason for open-source to adopt it, but when you see how fluid and connected it becomes to work together in open-source with Grace I expect it'll catch on.
> what is the future that you forsee for Grace? How would you spread its adoption without individual developers using it?
Short version:
Git is reaching it's EOL, for a few reasons. Grace is intended to be ready to meet the actual needs of developers in the late 2020's, not the mid-2000's like Git. Individual developers will use it. And the UX is so much better once you try it that it won't be a hard sell for most.
Longer version:
Git, as used today by most everyone, is a centralized version control system, that we access through a confusing distributed version control UX. Unless you push to production from your dev box, you're only shipping code by running `git push` and seeing that code run through some centralized CI/CD pipelines. This is one indication that the use case for Git, and the design of Git, have diverged enough to look like it's time for something new to come.
We all have to come to terms with the fact that we've found Git's fundamental design limits. As monorepos have come into fashion - and if we do nothing else in this industry, we follow fashion trends - we're seeing more and more that the only way to do large monorepos well is to use `git scalar` and partial clones so we don't clog our machines and Git servers with unnecessary traffic.
Once you're using `git scalar`, you're explicitly using Git as a centralized version control system, to run a repo that's centralized on a hoster, and the size of those repos forces GitHub and GitLab etc. to constantly invest in how to scale up the server side to match customer demands. Don't forget, the hosters all run Git protocol, but how they store data behind that protocol is the secret sauce of taking a mid-2000's client/server thing like Git and making it web-scale, and the demands on that scaling are only going up.
So, we've broken the client-side contract of Git - Git has the full repo on every machine! - with partial clones, and at some point the only way to scale up the server side is to not use Git repos, and break them up into object storage (this is what Azure DevOps does). So... it's no longer Git on the client, and it's no longer Git on the server. Why are we clinging to this thing?
This is what it looks like when a technology has reached it's EOL, and it's time to find something new.
Individual developers will 100% be using it... we'll all have the same free accounts on GitHub or GitLab or whatever hoster we use, and when we start up projects, they'll just be in Grace repos at those hosters. The vast majority of developers don't care how their version control works, they just want it to work. Grace is so much easier to understand than Git, and few people care about how much is local and how much is cloud, as long as it works and it's fast.
No one will force you to use Grace for your individual projects, but at some point, after using Grace, I don't think you'll want to go back. If you want to keep using Git yourself, it's not going anywhere.
I find it amusing how attached to "local repos" some devs have become when we have everything else we do live in the cloud, or synced to the cloud, and it's not a big deal. Source control isn't a different category of thing that must be local. It's just a no-longer-relevant habit from Git.
[1] https://github.com/ScottArbeit/Grace/blob/main/docs/Design%2...