7 ms·

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 cont

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.
- karmajunkie 2y ago
  if it makes you feel better i’ve been using it ~20 years and still learning…
yjftsjthsd-h 2y ago
>> easy to use, easy to understand > 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.
- chipdart 2y ago
  > Really? Because every team I've ever met could use git but the moment anything left the golden path they had to either (...) I've been using Git for over a decade and I never had the need to "delete everything, reclone". The only time I screwed up a Git repo was when I was experimenting with storing Git repos in USB pens and one of them got corrupted. I have no idea what might lead anyone to screw up a Git repo, because that's simply unrealistic.
  - eternityforest 2y ago
    The easiest way is to change a commit you've already pushed, and that something somewhere else references, and then force push it.
    - chipdart 2y ago
      > (...) and then force push it. I don't think this is a good example. Forcing a push means that the repository will lose commits, but you still keep yours in your local branch. This means the repo is not broken, but at best you have a perfectly valid local repository that just happens to be out of sync. If you rename your local branch and set it to not track the remote one, and afterwards you fetch changes from the remote branch, then you're done.
SBArbeit 2y ago
> 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.
chipdart 2y ago
> 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.

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.
karmajunkie 2y ago
if it makes you feel better i’ve been using it ~20 years and still learning…

yjftsjthsd-h 2y ago

>> easy to use, easy to understand > 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.

chipdart 2y ago
> Really? Because every team I've ever met could use git but the moment anything left the golden path they had to either (...) I've been using Git for over a decade and I never had the need to "delete everything, reclone". The only time I screwed up a Git repo was when I was experimenting with storing Git repos in USB pens and one of them got corrupted. I have no idea what might lead anyone to screw up a Git repo, because that's simply unrealistic.
- eternityforest 2y ago
  The easiest way is to change a commit you've already pushed, and that something somewhere else references, and then force push it.
  - chipdart 2y ago
    > (...) and then force push it. I don't think this is a good example. Forcing a push means that the repository will lose commits, but you still keep yours in your local branch. This means the repo is not broken, but at best you have a perfectly valid local repository that just happens to be out of sync. If you rename your local branch and set it to not track the remote one, and afterwards you fetch changes from the remote branch, then you're done.

SBArbeit 2y ago

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

chipdart 2y ago

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