3 ms·

> Also this means I can't easily run it locally? It's not meant to be a local version control system, unless you enjoy running local Kubernetes clusters (which

> Also this means I can't easily run it locally? 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.

tasuki 2y ago
> It's meant to be the next big thing in version control I wish you the best but kind of hope it isn't. I want my vcs to be local and conceptually simple. I definitely don't want a client-server architecture! > And I almost always get laughs and head nods when I talk about the problems with Git's UX. Yes, the UX is bad. But it's conceptually simple: blobs, trees, commits, pointers (branches etc). I really fear someone will replace Git with something having a better UX but conceptually much more complex. Complexity bad. We've gone over this so many times as an industry and we haven't learned yet. Complexity bad.
- SBArbeit 2y ago
  I agree, complexity bad. So why do you like Git? :-) Git is _incredibly_ complex to understand, as proven for almost 20 years by the vast majority of people who have been forced to use it. And by quite a bit of academic and industry research, for instance, [1]. I can teach you Grace in about 15 minutes. How many days and weeks does it take most devs to start to understand Git? And even when they do, for most, it's only the basics, and please don't let anything go wrong. I mean, there were people for over a decade who made their living running week-long workshops on learning Git. I don't see how you could run a half-day-long workshop teaching Grace, unless you go really slowly. If you're one of the probably 20% or so who really feels like they understand Git and are in control of it, that's awesome. But you're projecting your experience more widely if you think that's the norm. It's not. As for local, well, if you're working with a team on GitHub or GitLab or Azure DevOps or some other hoster, you're already doing centralized VCS, you're just using a decentralized VCS to do it. Most shops don't let you push to production from your dev box, right? [1]: https://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/42942.pdf https://static.googleusercontent.com/media/research.google.c...
  - _lvbh 2y ago
    > How many days and weeks does it take most devs to start to understand Git? A few weeks to understand a technology you’re gonna be working with for years to come is nothing. > And by quite a bit of academic and industry research, for instance, [1]. Isn’t that a positive aspect? It’s well studied and there are wealths of info about it for just about anything you need to do. I see Grace less as a git replacement and more as its own niche. I certainly see the benefits of easier onboarding and centralization for companies and education but those who grew up with git will likely keep using it Personally, I avoid anything “cloud-native”
  - chipdart 2y ago
    > I agree, complexity bad. So why do you like Git? :-) I think you're trying to fabricate problems where there are none. Git's UX problem lies in the way it's CLI is not intuitive for those unfamiliar with it, but a) using GUI frontends like SourceTree allows newbies to eliminate that issue, b) with time you onboard to the CLI and everything just works. At best, your suggestion to use another user interface is equivalent to suggesting Git users to adopt a new GUI frontend that's polished in a different way. > Git is _incredibly_ complex to understand, I don't know what you can possibly mean by "incredibly complex". For end users, your mental model can be limited to a) you clone a repository, b) you commit and your changes, c) you push your changes to make them available to everyone, d) you pull everyone's changes to have access to them. This is hardly rocket science. I mean, why do you think Git managed to become the world's de facto standard VCS and sets the gold standard for VCSs?
chipdart 2y ago
> 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). You should be clear about what is a major design trait, and arguably a major design flaw. Also, there is already standard terminology for this: centralized VCS. I don't understand why you decided to avoid objective descriptions of your project's single most important design trait and instead resort to vague meaningless buzzwords like "cloud-native" or "real-time". In fact, in light of this those terms start to sound like weasel words used to deceive the reader.
- SBArbeit 2y ago
  When I hear "cloud-native" I think "built to scale up well". As opposed to "built to run on file servers" which means "doesn't scale well at all". Is that just me? Also, [1]. I start by saying it's centralized. I'm proud of it. It's the right direction for moving version control forward. And modern use of Git isn't really distributed anyway; it's centralized. We don't push to production from our dev boxes. [1] https://github.com/ScottArbeit/Grace/blob/main/docs/Frequently%20asked%20questions.md https://github.com/ScottArbeit/Grace/blob/main/docs/Frequent....
  - roelschroeven 2y ago
    Hm. To me, cloud-native screams and PaaS completely out of my control and completely subject to the whims of some company that does not have my best interest in mind. It implies the impossibility of firing up some local instance for experimenting without having fear of leaving traces. In short, something to be avoided if possible.
dgrin91 2y ago
> 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. Sure if you want to push, but only maybe 10% of my Git commands relate to pushing/internet related stuff. The majority of my work is local-only commands that can be run on an airplane without wifi. Git lets me defer the internet required stuff to a later time. Its not clear Grace will allow me to do that at all. Also I once had a case of working on an air-gapped network. That was an interesting case that I'm not sure Grace would be suitable for at all? Granted that's super niche.
- SBArbeit 2y ago
  The fact that most of your Git commands are local-only is an artifact of how Git works, but I expect that ~100% of the time, you have an internet connection, so the fact that Grace needs to be connected to the cloud just isn't a thing I worry about. I'm not writing a new VCS based on the 0.00000001% "but I'm on an airplane without WiFi" case. There's ~0% reason in 2024 to build software for offline use cases, and even less reason in 2026 and 2028. I'm happy to cede that to Git if you really need it. As an industry, we fetishize offline for version control only because Git sort-of does that. Again, it doesn't really... you still have to push to do real work with your team, but we need to stop pretending that's a hard requirement. It's totally not, it's just a "feature" of Git that gets in our way today more than it helps us. > Also I once had a case of working on an air-gapped network. Coming from Microsoft, and being familiar with the air-gapped Azure instances for government, I designed Grace to be able to run on those Azure clouds. In other words, all of the PaaS services that Grace would use on Azure are present in those clouds. Even the air-gapped world isn't "offline", it's totally networked, just on a network that's not connected to the Internet. I haven't specifically looked at similar AWS instances, but I have to believe it's possible there, too.

tasuki 2y ago

> It's meant to be the next big thing in version control I wish you the best but kind of hope it isn't. I want my vcs to be local and conceptually simple. I definitely don't want a client-server architecture! > And I almost always get laughs and head nods when I talk about the problems with Git's UX. Yes, the UX is bad. But it's conceptually simple: blobs, trees, commits, pointers (branches etc). I really fear someone will replace Git with something having a better UX but conceptually much more complex. Complexity bad. We've gone over this so many times as an industry and we haven't learned yet. Complexity bad.

SBArbeit 2y ago
I agree, complexity bad. So why do you like Git? :-) Git is _incredibly_ complex to understand, as proven for almost 20 years by the vast majority of people who have been forced to use it. And by quite a bit of academic and industry research, for instance, [1]. I can teach you Grace in about 15 minutes. How many days and weeks does it take most devs to start to understand Git? And even when they do, for most, it's only the basics, and please don't let anything go wrong. I mean, there were people for over a decade who made their living running week-long workshops on learning Git. I don't see how you could run a half-day-long workshop teaching Grace, unless you go really slowly. If you're one of the probably 20% or so who really feels like they understand Git and are in control of it, that's awesome. But you're projecting your experience more widely if you think that's the norm. It's not. As for local, well, if you're working with a team on GitHub or GitLab or Azure DevOps or some other hoster, you're already doing centralized VCS, you're just using a decentralized VCS to do it. Most shops don't let you push to production from your dev box, right? [1]: https://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/42942.pdf https://static.googleusercontent.com/media/research.google.c...
- _lvbh 2y ago
  > How many days and weeks does it take most devs to start to understand Git? A few weeks to understand a technology you’re gonna be working with for years to come is nothing. > And by quite a bit of academic and industry research, for instance, [1]. Isn’t that a positive aspect? It’s well studied and there are wealths of info about it for just about anything you need to do. I see Grace less as a git replacement and more as its own niche. I certainly see the benefits of easier onboarding and centralization for companies and education but those who grew up with git will likely keep using it Personally, I avoid anything “cloud-native”
- chipdart 2y ago
  > I agree, complexity bad. So why do you like Git? :-) I think you're trying to fabricate problems where there are none. Git's UX problem lies in the way it's CLI is not intuitive for those unfamiliar with it, but a) using GUI frontends like SourceTree allows newbies to eliminate that issue, b) with time you onboard to the CLI and everything just works. At best, your suggestion to use another user interface is equivalent to suggesting Git users to adopt a new GUI frontend that's polished in a different way. > Git is _incredibly_ complex to understand, I don't know what you can possibly mean by "incredibly complex". For end users, your mental model can be limited to a) you clone a repository, b) you commit and your changes, c) you push your changes to make them available to everyone, d) you pull everyone's changes to have access to them. This is hardly rocket science. I mean, why do you think Git managed to become the world's de facto standard VCS and sets the gold standard for VCSs?

chipdart 2y ago

> 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). You should be clear about what is a major design trait, and arguably a major design flaw. Also, there is already standard terminology for this: centralized VCS. I don't understand why you decided to avoid objective descriptions of your project's single most important design trait and instead resort to vague meaningless buzzwords like "cloud-native" or "real-time". In fact, in light of this those terms start to sound like weasel words used to deceive the reader.

SBArbeit 2y ago
When I hear "cloud-native" I think "built to scale up well". As opposed to "built to run on file servers" which means "doesn't scale well at all". Is that just me? Also, [1]. I start by saying it's centralized. I'm proud of it. It's the right direction for moving version control forward. And modern use of Git isn't really distributed anyway; it's centralized. We don't push to production from our dev boxes. [1] https://github.com/ScottArbeit/Grace/blob/main/docs/Frequently%20asked%20questions.md https://github.com/ScottArbeit/Grace/blob/main/docs/Frequent....
- roelschroeven 2y ago
  Hm. To me, cloud-native screams and PaaS completely out of my control and completely subject to the whims of some company that does not have my best interest in mind. It implies the impossibility of firing up some local instance for experimenting without having fear of leaving traces. In short, something to be avoided if possible.

dgrin91 2y ago

> 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. Sure if you want to push, but only maybe 10% of my Git commands relate to pushing/internet related stuff. The majority of my work is local-only commands that can be run on an airplane without wifi. Git lets me defer the internet required stuff to a later time. Its not clear Grace will allow me to do that at all. Also I once had a case of working on an air-gapped network. That was an interesting case that I'm not sure Grace would be suitable for at all? Granted that's super niche.

SBArbeit 2y ago
The fact that most of your Git commands are local-only is an artifact of how Git works, but I expect that ~100% of the time, you have an internet connection, so the fact that Grace needs to be connected to the cloud just isn't a thing I worry about. I'm not writing a new VCS based on the 0.00000001% "but I'm on an airplane without WiFi" case. There's ~0% reason in 2024 to build software for offline use cases, and even less reason in 2026 and 2028. I'm happy to cede that to Git if you really need it. As an industry, we fetishize offline for version control only because Git sort-of does that. Again, it doesn't really... you still have to push to do real work with your team, but we need to stop pretending that's a hard requirement. It's totally not, it's just a "feature" of Git that gets in our way today more than it helps us. > Also I once had a case of working on an air-gapped network. Coming from Microsoft, and being familiar with the air-gapped Azure instances for government, I designed Grace to be able to run on those Azure clouds. In other words, all of the PaaS services that Grace would use on Azure are present in those clouds. Even the air-gapped world isn't "offline", it's totally networked, just on a network that's not connected to the Internet. I haven't specifically looked at similar AWS instances, but I have to believe it's possible there, too.