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