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