6 ms·

Hi! I created Grace. AMA...

by SBArbeit 2y ago

hestefisk 2y ago
Have you registered gracehub.com yet? :)
- SBArbeit 2y ago
  lol no, I did not. 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.
- jFriedensreich 2y ago
  wouldnt it be graceland.com ?
  - SBArbeit 2y ago
    Eh, I'm not really an Elvis fan... One of the problems that GitHub and GitLab are going to face in the coming years, as Git gets supplanted whatever wins, is that "Git" is in the company name. Those names are going to sound they like provide yesterday's tech, in a hurry. Not gonna make that same mistake for Grace.
mobilejdral 2y ago
Some feedback: In the readme file at the top you want to describe the problems that Grace solves. This is what I read and parsed: > 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?
- andoando 2y ago
  To be fair Ive been using for git for 8 years and I still dont quite understand it beyond the basics.
  - SBArbeit 2y ago
    You're not alone. My experience is that about 20% of devs deeply understand Git and are very comfortable with it, and about 80% know the the basics and hope nothing goes wrong. I'm somewhere in the middle myself. That's part of why I designed Grace to be much easier to understand. I can teach it to you in about 15 minutes, not the days and weeks it takes all of us to feel like we understand Git.
  - chipdart 2y ago
    > To be fair Ive been using for git for 8 years and I still dont quite understand it beyond the basics. I don't see why this is supposed to be a problem. What constitutes "the basics" is what you use in your everyday routine, and if that works perfectly well then there is absolutely no need to do something you never need to do.
    - fragmede 2y ago
      while I don't judge someone for not knowing past the basics of git because, as you point out, if it works, it works, the very valid fear is that they'll somehow get into a funky state and have to find a git expert to fix it for them, or painfully muddle through it, with the very real fear that their work will get lost somehow. if you know what you're doing, that doesn't happen, but if you're not an expert, it's a very real thing that can happen, so it's that fear that constitutes a problem for some. it's this black box that saves all my hard work, and if it accidentally hit the wrong button, it'll delete all my data and find my kids and scare them as well. I was fortunate enough to dive deep into git professionally so I'm good enough with it to get myself out of trouble, but watching others use it, I can understand their worry.
    - andoando 2y ago
      Its gotten me along so I havent bothered, but occasionally I will fall into a mess and I find some improper/inefficient ways around it. Every time I try interwctive rebase I get into a huge mess where it cant apply some updates for some reason and I say f it and just do git reset hard and aoply the commits I want and force push.
tasuki 2y ago
When are you planning to use Grace to develop Grace?
- SBArbeit 2y ago
  Awesome question. 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.
ulrikrasmussen 2y ago
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.
- SBArbeit 2y ago
  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.
  - chipdart 2y ago
    > A better question is: why does git only have one gesture for it, when devs clearly use it to mean different things already? Do they, though? I mean, most users simply use a GUI layer on top of Git, and thus often are oblivious to what Git is doing under the hood. > 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. No, not really. At best it's a debate over which branching strategy a team wants to standardize over. I happen to be working in a team which after months of doing non-ff merges of PRs it's starting to favor squash merges, and there is absolutely no discussion over the topic. Everything boiled down to "the history looks noisy, let's squash to remove noise as GitHub still tracks feature branches", followed by "sure, why not? If this doesn't work out we can fall back to non-ff". Done.
chipdart 2y ago
> Hi! I created Grace. AMA... 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.
- tichiian 2y ago
  > irrelevant for a VCS (cloud-native?!) 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.
  - maccard 2y ago
    And it sounds great to me - knowing that my 99% use case isn’t going to encumbered by one person who insists that we send patches via email
    - SBArbeit 2y ago
      ^ this
  - SBArbeit 2y ago
    "Cloud-native", to me, means "built to scale up well". I find that's the connotation that most people associate with it. Git, or any file-server based software, is not built to scale up well in today's world. Large Git hosters have to invest entire teams to manage their file servers and their Git front-end systems to create a web-scale service on top of a file-server based piece of software. I'm just skipping to the part where you don't need that anymore because Azure / GCP / AWS PaaS services already handle that. And, in any team dev situation, you're not getting anywhere until you `git push`, and that requires an internet connection. Assuming ~100% connectivity for devs around the world, in the late 2020's, is the right assumption to make. If offline is a hard requirement, Git isn't going anywhere. > through non-http transports like mail yeah, I'm not building a new VCS for that 0.0000001% case.
qznc 2y ago
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. I wrote about it more extensively here: https://beza1e1.tuxen.de/monorepo_vcs.html https://beza1e1.tuxen.de/monorepo_vcs.html
- tichiian 2y ago
  Now this starts to sound like ClearCase. (me shuddering in disgust)
- SBArbeit 2y ago
  > 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.
zeotroph 2y ago
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.
- indymike 2y ago
  > 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.
- thfuran 2y ago
  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.
  - robertlagrant 2y ago
lordnacho 2y ago
Might as well ask the hard question: I've invested a lot of time into getting used to git. What are my gains from learning grace?
junto 2y ago
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.
skybrian 2y ago
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. [1] https://github.com/ScottArbeit/Grace/blob/main/docs/Branching%20strategy.md https://github.com/ScottArbeit/Grace/blob/main/docs/Branchin...
thanzex 2y ago
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?
nycdotnet 2y ago
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?
- SBArbeit 2y ago
  > Hi - can Grace support partial commits somehow? Not at the moment, and probably not for v1.0 unless that bubbles up as a huge blocker. You could accomplish it with something like: - Make the changes in your branch - Make a new branch off of `main` and cherry-pick the changes you want from your branch into that new one - Commit and promote from the new branch; at this point you can delete the new branch - Auto-rebase will run and propose a good merge to your original branch, which would include the partial changes you now have both in `main` and in your branch. I still have to write cherry-pick - not sure that I'll call it that - and promotion conflict processing using LLM's. But something like the above steps would do what you're asking without too much effort. There's no way to tackle the entire surface area of 20 years of Git in one release. I'm sure we'll see workarounds like that in v1.0 and learn from them to improve 2.0 and 3.0.

Hi! I created Grace. AMA...

hestefisk 2y ago

Have you registered gracehub.com yet? :)

SBArbeit 2y ago
lol no, I did not. 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.
jFriedensreich 2y ago
wouldnt it be graceland.com ?
- SBArbeit 2y ago
  Eh, I'm not really an Elvis fan... One of the problems that GitHub and GitLab are going to face in the coming years, as Git gets supplanted whatever wins, is that "Git" is in the company name. Those names are going to sound they like provide yesterday's tech, in a hurry. Not gonna make that same mistake for Grace.

mobilejdral 2y ago

Some feedback: In the readme file at the top you want to describe the problems that Grace solves. This is what I read and parsed: > 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?

andoando 2y ago
To be fair Ive been using for git for 8 years and I still dont quite understand it beyond the basics.
- SBArbeit 2y ago
  You're not alone. My experience is that about 20% of devs deeply understand Git and are very comfortable with it, and about 80% know the the basics and hope nothing goes wrong. I'm somewhere in the middle myself. That's part of why I designed Grace to be much easier to understand. I can teach it to you in about 15 minutes, not the days and weeks it takes all of us to feel like we understand Git.
- chipdart 2y ago
  > To be fair Ive been using for git for 8 years and I still dont quite understand it beyond the basics. I don't see why this is supposed to be a problem. What constitutes "the basics" is what you use in your everyday routine, and if that works perfectly well then there is absolutely no need to do something you never need to do.
  - fragmede 2y ago
    while I don't judge someone for not knowing past the basics of git because, as you point out, if it works, it works, the very valid fear is that they'll somehow get into a funky state and have to find a git expert to fix it for them, or painfully muddle through it, with the very real fear that their work will get lost somehow. if you know what you're doing, that doesn't happen, but if you're not an expert, it's a very real thing that can happen, so it's that fear that constitutes a problem for some. it's this black box that saves all my hard work, and if it accidentally hit the wrong button, it'll delete all my data and find my kids and scare them as well. I was fortunate enough to dive deep into git professionally so I'm good enough with it to get myself out of trouble, but watching others use it, I can understand their worry.
  - andoando 2y ago
    Its gotten me along so I havent bothered, but occasionally I will fall into a mess and I find some improper/inefficient ways around it. Every time I try interwctive rebase I get into a huge mess where it cant apply some updates for some reason and I say f it and just do git reset hard and aoply the commits I want and force push.

tasuki 2y ago

When are you planning to use Grace to develop Grace?

SBArbeit 2y ago
Awesome question. 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.

ulrikrasmussen 2y ago

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.

SBArbeit 2y ago
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.
- chipdart 2y ago
  > A better question is: why does git only have one gesture for it, when devs clearly use it to mean different things already? Do they, though? I mean, most users simply use a GUI layer on top of Git, and thus often are oblivious to what Git is doing under the hood. > 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. No, not really. At best it's a debate over which branching strategy a team wants to standardize over. I happen to be working in a team which after months of doing non-ff merges of PRs it's starting to favor squash merges, and there is absolutely no discussion over the topic. Everything boiled down to "the history looks noisy, let's squash to remove noise as GitHub still tracks feature branches", followed by "sure, why not? If this doesn't work out we can fall back to non-ff". Done.

chipdart 2y ago

> Hi! I created Grace. AMA... 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.

tichiian 2y ago
> irrelevant for a VCS (cloud-native?!) 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.
- maccard 2y ago
  And it sounds great to me - knowing that my 99% use case isn’t going to encumbered by one person who insists that we send patches via email
  - SBArbeit 2y ago
    ^ this
- SBArbeit 2y ago
  "Cloud-native", to me, means "built to scale up well". I find that's the connotation that most people associate with it. Git, or any file-server based software, is not built to scale up well in today's world. Large Git hosters have to invest entire teams to manage their file servers and their Git front-end systems to create a web-scale service on top of a file-server based piece of software. I'm just skipping to the part where you don't need that anymore because Azure / GCP / AWS PaaS services already handle that. And, in any team dev situation, you're not getting anywhere until you `git push`, and that requires an internet connection. Assuming ~100% connectivity for devs around the world, in the late 2020's, is the right assumption to make. If offline is a hard requirement, Git isn't going anywhere. > through non-http transports like mail yeah, I'm not building a new VCS for that 0.0000001% case.

qznc 2y ago

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. I wrote about it more extensively here: https://beza1e1.tuxen.de/monorepo_vcs.html https://beza1e1.tuxen.de/monorepo_vcs.html

tichiian 2y ago
Now this starts to sound like ClearCase. (me shuddering in disgust)
SBArbeit 2y ago
> 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.

zeotroph 2y ago

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.

indymike 2y ago
> 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.
thfuran 2y ago
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.
- robertlagrant 2y ago

lordnacho 2y ago

Might as well ask the hard question: I've invested a lot of time into getting used to git. What are my gains from learning grace?

junto 2y ago

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.

skybrian 2y ago

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. [1] https://github.com/ScottArbeit/Grace/blob/main/docs/Branching%20strategy.md https://github.com/ScottArbeit/Grace/blob/main/docs/Branchin...

thanzex 2y ago

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?

nycdotnet 2y ago

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?

SBArbeit 2y ago
> Hi - can Grace support partial commits somehow? Not at the moment, and probably not for v1.0 unless that bubbles up as a huge blocker. You could accomplish it with something like: - Make the changes in your branch - Make a new branch off of `main` and cherry-pick the changes you want from your branch into that new one - Commit and promote from the new branch; at this point you can delete the new branch - Auto-rebase will run and propose a good merge to your original branch, which would include the partial changes you now have both in `main` and in your branch. I still have to write cherry-pick - not sure that I'll call it that - and promotion conflict processing using LLM's. But something like the above steps would do what you're asking without too much effort. There's no way to tackle the entire surface area of 20 years of Git in one release. I'm sure we'll see workarounds like that in v1.0 and learn from them to improve 2.0 and 3.0.