12 ms·

Grace Version Control System

137 points by davedx 2y ago

eternityforest 2y ago
Not being able to work offline at all seems like somewhat of an issue. 99% of the time it's fine, but if you have even one thing you want to do locally, now you have to use two separate tools. I'm not sure how many people have an absolute hard requirement for local operation, but it is a nice extra layer of peace of mind. Git might not be perfect, but it's one of the only tools witch such a large market share. All your projects can use the same VCS, which is really nice. On the other hand, some programmers seem to really like having different highly specialized tools for every job, rather than adapting jobs to fit the tools, so I'm sure there's demand for a new VCS there.
- gkhartman 2y ago
  I don't develop offline often these days, but I do recall a recent time where my power went out for a few hours. Since I was using git on my laptop, I just shrugged and kept working. Using git allowed me to continue working in a flow state that would have normally been interrupted by a dropped connection. Of course, if your project doesn't run locally, that point is moot. For others, in areas with more power/connection interruptions, the time savef would add up.
  - vandahm 2y ago
    I don't develop offline, but I've developed the habit of making lots of tiny commits, then rebasing them into a single commit before pushing. To me, a commit is for something I might want to undo and a push is for something that I either want to share or am afraid of losing. I'm not suggesting this is the best way to use version control or even a good way -- just that it's a habit I've developed and don't really want to unlearn.
- kstrauser 2y ago
  Almost all of us have that requirement sometimes. Working from a hotel coffee bar and the WiFi goes out? Bummer if that blocks your work. I’m online 98% of the time. My local tooling works 100% of the time. I’d want to defenestrate my laptop if it stopped working for a silly reason.
  - riwsky 2y ago
    I don’t see how uninstalling Windows from your laptop is gonna solve hotel Wi-Fi problems—but power to you, I guess.
    - kstrauser 2y ago
      When you’re done with that, you can pitch it off the balcony.
  - SBArbeit 2y ago
    > Working from a hotel coffee bar and the WiFi goes out? Bummer if that blocks your work. Grace doesn't change anything about that for you. You still write code locally, and `grace watch` will sync you up when you reconnect. You can't `git push` without an internet connection, either, and you can't work on your Azure / GCP / AWS resources. Or your Google Docs. Or your email. Or your Teams chat. Source control isn't a special case that must work offline, it's just that we're used to Git, and we pay the bad-UX tax of using a distributed VCS as a centralized VCS, because very few of us push to production from our dev boxes, only from a (Git)hub. Assuming a working internet connection in the late 2020's (i.e. roughly when Git will be replaced by some competitor) is not a blocker for almost every developer in the world. And Git will still be there if offline usage is a hard requirement.
    - eternityforest 2y ago
      Can you commit/checkpoint/branch offline?
    - thfuran 2y ago
      >in the late 2020's (i.e. roughly when Git will be replaced by some competitor) I'd put it at more like the late 2050s. I think it achieved critical mass. It certainly doesn't look like it's going anywhere in the next few years.
    - kstrauser 2y ago
      Hard disagree. It’s inherently true that I can’t work on remote servers and all those things but VCS are not inherently remote. I have entire local hobby projects I’ve never git pushed anywhere because my local copy is authoritative. We as an industry largely moved off centralized VCS because of those advantages of having 100% functionality on an airplane.
- PontifexMinimus 2y ago
  > Not being able to work offline at all seems like somewhat of an issue. I agree. If it's intended to be a web-based system, why not have it running as a webserver on your local machine? Also, the intention is to have a GUI, or rather 4 or 5 seeparate GUIs: > Grace will have a native GUI app for Windows, Mac, Android, and iOS. (And probably Linux.) But if you're having a web UI, why have a GUI as well? It is just extra work, and it is quite likely that the UI for these tools won't be the same, potentially making them harder to learn.
  - SBArbeit 2y ago
    The intention is that they'll be identical, because they'll be written using Avalonia. And I hate Electron. I hate it so much. I hate the web pages that I'm being told are "apps". I hate the lack of keyboard shortcut support. I hate the bad performance. I hate how it's not stick-to-your-finger fast. I hate owning unbelievably powerful computers and mobile devices and not taking advantage of their power and capabilities, and just reducing them to surfaces for fake "apps". I refuse to not deliver native apps with Grace.
    - kstrauser 2y ago
      This we can agree on. Thanks for making that a design goal!
    - PontifexMinimus 2y ago
      > And I hate Electron I'm not a fan of it either. When I say have a web UI, I don't mean electron, I mean the program runs as a web server on some port your local machine and you point you web browser at it. I don't think electron should exist. > I hate the lack of keyboard shortcut support And I hate the existence of keyboard shortcuts, or at least hard-to-discover ones. On a daily basis I accidentally press keys (I've no idea which ones) that make my windows misbehave. I also don't think I should have to learn keyboard shortcuts -- interfaces should be discoverable and not require you to memorise stuff. > I hate the bad performance. Then use a text UI not a GUI. Back in the day, Borland made extensive use of these for Turbo Pascal and they worked well and looked good. As a bonus (like a web app) they can run easily on an external machine. > I hate how it's not stick-to-your-finger fast. I've used git for years and before it other source control systems. I don't remember a single instance where the slowness of the source control system was ever a factor.
gavinhoward 2y ago
Well, shoot. I am working on a new VCS too, and Grace seems to have most of what I want in mine. The only two things mine might do better are large binary files (because I do think they belong in version control) and decentralization.
- lagniappe 2y ago
  > The only two things mine might do better are large binary files (because I do think they belong in version control) Alright you got me, I'm listening
  - gavinhoward 2y ago
    Ah, didn't expect interest. I want to track changes to binary files the way we do with text. [1] For example, if you have a PNG texture, my VCS will track changes at the pixel level. If you have a Blender file, it will track changes at the item level, from meshes to materials and vertices, and everything in-between. Yes, it will be a lot of manual work to implement each file type, but that's how I plan to make money. [1]: Only files that use lossless compression, of course.
    - albertzeyer 2y ago
      Interesting idea. I assume with quite a number of technical difficulties (even despite the manual work for each file type). However, I don't think making money from this will work. A new version control system must be 100% open source. Otherwise it will not be an option for most people. Even when only selling extensions for certain file types and keeping the core open source, I don't think this will work, as you keep away the main interesting feature then.
      - gavinhoward 2y ago
        FWIW, I think you are absolutely right. However, my target audience isn't developers; my target is users of Perforce, which is closed source. So I think a source available [1] VCS will be palatable for that audience. I could be wrong, though. [1]: https://gavinhoward.com/2023/12/is-source-available-really-that-bad/ https://gavinhoward.com/2023/12/is-source-available-really-t...
calvinmorrison 2y ago
I am sorry, maybe I am a boomer but I don't like it one bit. > Grace is a new, modern, cloud-native version control system. The whole point of git was to replace crappy centralized solutions > Grace Server scales up by running on Kubernetes and massive PaaS services from large cloud providers. word salad > Every save is uploaded, automatically Can't wait for the passwords to start leaking. Grace simplifies this by breaking these usages out into their own gestures and events: > grace checkpoint - this means "I'm partially done", for you to keep track of your own progress > grace commit - this is "I'm really done" or "This version is a candidate for promotion"; you'd use a commit for a PR > grace promote - in Grace, promotions replace merges; a promotion is how Grace moves code from a child branch to a parent branch I have no problem with this, I even like it. Some around here will remember before "MRs", well then called "PRs" were ubiquitous, Git can provide different workflows. We can write tools on top of git, like github, to do more fancy things. I think it's high time for some new concepts backed by git > When your parent branch gets updated, within seconds, grace watch will auto-rebase your branch on those changes, so you're always coding against the latest version that you'll have to promote to. I don't think I ever wanted to auto rebase on every time I save. In fact, I think I really don't like this... in fact, we might as well just all start co-editing on the same server > Personal branches, not forks > With Grace, there's no need for forking entire repositories just to make contributions. In open-source repos, you'll just create a personal branch against the repo. This is what everyone does normally, except Github made forks a thing or whatever so you could clone someone elses repo and hack on it without having mainline permissions.
- chrisallenlane 2y ago
  > Personal branches, not forks > With Grace, there's no need for forking entire repositories just to make contributions. In open-source repos, you'll just create a personal branch against the repo. > This is what everyone does normally, except Github made forks a thing or whatever so you could clone someone elses repo and hack on it without having mainline permissions. Yeah. I'm an open-source maintainer and the "everyone creates a branch on upstream" model is a complete non-starter for me, even if only due to the mess it would cause. This is a massive step backward from "fork and pull."
krick 2y ago
Honestly cannot tell at the first glance if it's a joke. "Welcome to Grace" feels like it obviously must be a joke. But then it's kinda too elaborate for a joke (and not very original one too). So…?
- khazhoux 2y ago
  You're really gonna have to fill the rest of us in on what could possibly be joke-like about the throwaway intro line "Welcome to Grace." And "not very original" makes it sound like in your world, "Welcome to Grace" is a common joke of sorts. ??
ilc 2y ago
The centralization and also the monitoring are hard nopes for me. If the monitoring was all local and not pushed up to k8s instantly, maybe. But this screams of a PHB's wet dream. As someone who has maintained forks of large FOSS code bases. This also makes doing that harder. I wasn't interested in sharing my changes. But I wanted SCM to allow me to merge upstream's changes. This feels like a step back to systems like Clearcase, and I.. Just don't want it.
- deepsun 2y ago
  PHB -- do you mean Portland Housing Bureau, Pedestrian Hybrid Beacons or Polyhydroxybutyrate?
  - voidfunc 2y ago
    Pointy Haired Boss... Dilbert... Ugh now I feel old and I'm only in my 30s.
  - minasmorath 2y ago
    Player's Handbook.
  - ilc 2y ago
    Pointy Haired Boss. I now feel very old. Dilbert taught engineers how the world worked in a sarcastic over the top way. No wonder new engineers are confused :(
- deleted 2y ago
  [deleted]
samatman 2y ago
It appears that this solves exactly no problems which I have, while introducing a slew of problems I don't have currently and am grateful not to. I know this comment risks falling to the low-brow dismissal bucket, but it's hard for me to say anything more cogent than that. It all seems so obvious? Like, Kubernetes, your choice of cloud provider, "who works offline anyway"... No thanks.
- deleted 2y ago
  [deleted]
vouaobrasil 2y ago
Random thought, but I used to use version control (Git) for work. After I quit, I kept programming for fun...and to be honest I like programming without version control a lot better. I realized I hate version control. It imposes too much structure on programming, like having to keep all my drafts of the past. It's rather stifling in fact. Now, I know version control is super useful for large projects, especially of the commercial variety. But now I see all the modern software out there and I wonder if maybe the increasingly commercialization of the software world has in part been accelerated by version control, which makes programming more robotic and less artistic.
- metadat 2y ago
  I find git freeing and empowering, because I never have to worry about FOMO - I can rewind or pull up any past checkpoint.
- 000ooo000 2y ago
  Interesting perspective. I feel the opposite; in my personal projects, I love having Git because I can fearlessly rework things knowing I can just abandon the rework if it's not playing out, or stick the rework in a branch and come back to it later. Different strokes!
  - vouaobrasil 2y ago
    True enough! I like the lack of version control because it feels like surviving in the wilderness with less safety gear and more self-reliance, or swimming in a lake without a life guard.
    - snthpy 2y ago
      I guess people like soloing big walls of rock so if it works for you. My risk appetite is a lot lower and I try to use version control for everything.
- thfuran 2y ago
  >I realized I hate version control. It imposes too much structure on programming, Having used several different VCS, I have no idea what you're talking about. Are you conflating some complex CI/CD setup with branch naming schemes and oodles of hooks with version control in general? I mean, I think git is slightly overly opinionated when it comes to the relationship between commits and branches, but I don't get the impression that is what you mean.
kstrauser 2y ago
> Because grace watch automatically uploads new file versions after every save, … Nope. I type stuff all the time that I don’t want anyone else seeing. # I hate this ^#{=+ thing just work dammit Or password = ‘foo’ # TK fetch this from disk later Etc. I don’t want my computer sharing my scratch notes with my coworkers without me explicitly choosing to commit and push them. No way, no how. (Also the presumption of always online-dness. What?)
- SBArbeit 2y ago
  You can use Grace without running `grace watch`, but really it's a much better experience if you do. It makes version control more ambient, more something that just happens in the background. And you can delete any save or checkpoint that you don't want, it'll disappear. I mean, I assume you don't type curse words every time you edit a file. I don't... it's only like every 10 edits or so for me. ;-) Yes, I presume that almost every developer in the world, by the late 2020's, will have a working Internet connection ~100% of the time. If you still need some sort of offline VCS, Git will still be around. Treating source control as something that must work without an internet connection is just silly to me... we almost all use Git as a centralized version control system already. You can't push without an Internet connection, and most dev shops won't let you push to production without going through the (Git)hub first. It's not like Grace will prevent you from making changes; as soon as you have a connection again, `grace watch` will catch you up. Or don't use that and just do `grace rebase` or whatever. Up to you.
kstenerud 2y ago
> Every save is uploaded, automatically Nope. Last thing I want is for my repo to become huge just because I happened to temporarily create a big file inside the repository directory. Or passwords and credentials to leak because I needed to do a test run. I can see it now: A new kind of malware that repo bombs your organization by randomly creating 2TB files in some guy's repos. Every single person becomes the potential point of network collapse. > every save and commit, every branch name change, every everything, is stored as a separate event. Why would you DO that??? Every branch name change??? That's OCD level crazy. > Imagine: there's a promotion to main, your branch gets auto-rebased on those latest changes, and then your local unit test suite gets run automatically so you immediately know if there's a problem. Oh my god NO!!! The last thing I want is a ghost in the machine changing stuff while I'm working on my branch! Imagine the function you're working on changing mid-edit due to a rebase! What hell is being unleashed here? > Grace lets you share your code with team members effortlessly, around the world, for those times when you need another set of eyes on it, or just want to show them something cool. You can already do that! It's called a branch. > C'mon, it's 2024. There's got to be some AI in here, right? OMG Seriously??? > No stashing Okay, now you're just taking the piss... By this point I'm checking to see if it's April 1st.
- rigelbm 2y ago
  Imagine you did have an idea, put a lot of effort building it, just so that some random person takes a dump on your work. It wouldn't be nice, would it? Unnecessarily harsh and misses the point that this is a new VCS that brings valid new ideas to table. As with any new thing, if it's not for you, it's not for you. SBArbeit, ignore this kind of comment. Not because it's not valid feedback, but because it isn't worth it.
  - SBArbeit 2y ago
    Thank you. <3 I do ignore them. There's no way to build something with an intention as big as "replace Git" that won't invite knee-jerk reactions. I know I'm building the thing that aligns with my creative and technical vision. That's all I can do. It will succeed or it won't, and the reactions from people who are already super-comfortable with the existing technology matter less than the reactions from people who only understand the basics of Git and are afraid of it. I'm building it for them (which includes me).
senkora 2y ago
> AI to help resolve conflicts This does actually sound quite helpful, if your workflow involves frequent merges (and I feel for you if it does). I know that git has configurable merge strategies; has anyone written one that calls out to AI? https://git-scm.com/docs/merge-strategies https://git-scm.com/docs/merge-strategies
- bigfishrunning 2y ago
  I imagine it's like AI code generation: the work required to review the merge is very likely more then the work required to implement the merge.
- karpovv-boris 2y ago
  I guess marketing win if we're talking about ai (which is ML!) in context of some obvious and deterministic operation as merge. (go see rerere https://git-scm.com/docs/git-rerere https://git-scm.com/docs/git-rerere)
- SBArbeit 2y ago
  A big design driver for Grace is eliminating fear around using version control. Merge conflicts are one of the big places where fear can happen, even if it's subtle; you think you're all done with your work and then... ugh, what happened? are my changes stepping on the other changes? are they stepping on mine? do I have to retest? etc. Having an event-driven, automatic AI review of a conflict is just something that makes sense today. I don't just want to tell you there's a conflict, I want to tell you there's a conflict and give you a solution to it that you can accept with one click if it looks good. Grace will even be able to run CI/CD pipelines against that proposed resolution before it tells you about it to help you make the decision.
  - acureau 2y ago
    I'm not sure how that makes sense today, to me it's more of a novel idea than a solution to a problem. I use AI every day in my workflow and I honestly don't believe it's capable of reliably solving merge conflicts. GPT-4 can write a really nice method but can't integrate it into my code-base. If half of the proposed solutions are incorrect, I need to scrutinize all proposed solutions equally. Would I rather review likely inaccurate conflict resolutions, only to solve it myself afterwards, or resolve it myself from the get-go in a way that I know makes sense? Do I want to give my teammates the ability to click a button and introduce subtle merge bugs?
fredsmith219 2y ago
Does anybody else see the irony of storing a new version control system on GitHub?
- SBArbeit 2y ago
  It's an interesting problem, right? First, Grace is still an alpha, and isn't ready to be trusted for real yet. Too much work left to do, and so far it's just me. Second, as I open up to contributors, we need a place to work together. GitHub is the Home of Open Source. It's not just about the version control system; it's about the social network and features built around it, and right now GitHub has all of the other features, and I don't have time to build Repos, Issues, Discussions, PR's, Actions, and the rest of what GitHub has in addition to a VCS. At some point, I will run Grace's version control in Grace, and create a way to use GitHub Actions to automate things from there, while keeping Issues, PR's, Actions, etc. somehow in GitHub. It's a ways off, for sure.
mberning 2y ago
So now I need kubernetes to run and scale my vcs? That’s a no for me dawg.
CharlieDigital 2y ago
Did not expect to see F# and C#; pleasantly surprised.
- howtoagi 2y ago
  [dead]
- junto 2y ago
  I also noticed that. 95% F# too.
- SBArbeit 2y ago
  I'm a long-time C# dev who got into F# about five years ago. F# is so awesome, I hope that if Grace catches on, that more people will pay some attention to it. And .NET is so fast. No-brainer.
SBArbeit 2y ago
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?
TulliusCicero 2y ago
I like the idea of it being easy to use. I can get by with git and mercurial, but I find that occasionally I fuck things up and don't really know how to fix it other than manually copying some files around and blowing away a branch. A lot of the error messages just feel obtuse.
- deleted 2y ago
  [deleted]
gwbas1c 2y ago
IMO: 1: Lead with the most critical differentiators versus git. Source control systems are a dime-a-dozen. The "I can do this better" projects that fail are a dime-a-dozen. Get us hooked within the first 3 paragraphs. 2: I personally don't (usually) encounter performance issues with git. I get more from Visual Studio than git. The only performance issue are the random garbage collections, and those are infrequent. > When your parent branch gets updated, within seconds, grace watch will auto-rebase your branch on those changes 3: Automatically changing my code while I am working on it is a horrible idea. DO NOT DO THIS. Often, programming requires low distractions, and the distraction of changing the very thing that I am working on while I am working on it is a huge distraction. The dangers: - If I am trying to isolate a specific behavior, auto-rebase could change the behavior of what I'm trying to isolate while I'm trying to isolate it. - If the upstream rebase creates a build error, it will completely destroy my flow. (It makes me stop a task while I am incomplete.) This could happen if the parent branch has a renamed method, and my changes introduce a new call to that method. Instead, I suggest a very gentle notification about parent branch updates. Don't steal focus. Edit: I was lead developer on a desktop file sync client for 9 years. Whenever I had a support escalation from someone using us as source code control, I'd always recommend that the customer use git and tell them that we used Github. Source code repositories have A LOT of transient files that come and go very quickly, and are very hard on live file sync.
- deleted 2y ago
  [deleted]
howtoagi 2y ago
[dead]
pluto_modadic 2y ago
I guess I wouldn't use the "watch" command. ever. no thanks.
deleted 2y ago
[deleted]
okaleniuk 2y ago
I think, this is a step forward. I got used to real-time version tracking when I was working on a book. The publisher insisted that the working files are kept in the Box folder (like a DropBox, or any other cloud-shmoud synchronized storage). This was... convenient and practical. This way of working is much better than the Git way if you work alone and produce dozens or hundreds of meaningful changes a day. But at some point you have to publish. You have to make sure your state is correct to some level of certainty, and share it with other people. So you still need some kind of 'commit' thingie. I think, Grace gets this both ways right. Personally, I just keep GitHub repos in a DropBox folder, but if Grace catches on, I might consider hoping in.
- SBArbeit 2y ago
  Thank you. One of the original, first-night-dreaming-about-it inspirations for Grace was the OneDrive sync client; since they rewrote it back in like 2018 or whatever it's been so rock-solid, and it's ambient. I wanted that experience for version control; make as much happen in the background as possible, and make it fast when you need to interact with it.
  - tichiian 2y ago
    OneDrive sync and "rock-solid" in the same sentence? I beg to differ. Frequent conflicts due to non-synced files, the client crashing, randomly failing auth, files that are indicated to be recent and in sync but really aren't, no proper debuggability, no insight into why things don't work if they (frequently) don't. I could go on. OneDrive is a very bad thing to reference in this context.
    - SBArbeit 2y ago
      That hasn't been my experience for at least six years. I think I've had one weird sync issue with OneDrive, like a couple of years ago... I forget, but it just works, across all of my computers, in near-real-time.
- IshKebab 2y ago
  I think probably the big difference is "if you work alone". You have to go to extra effort with Git because you need your changes to be understandable and usable by other people. I dunno if this is the right thing for team based coding projects. I think we just need something like Git with: * A saner CLI * Proper support for large files * Proper support for submodules * Better conflict resolution I think Pijul goes some way towards some of those, especially the last one, and maybe submodules.
2d8a875f-39a2-4 2y ago
Interesting but this page reads like a marketing piece. The discourse around VCSs is mature and you should BLUF with where yours sits in the spectrum of alternatives. What is the repository model and the concurrency model? Those are the basics. Seems to be centralized & um, merge or lock, maybe? I don't want to have to parse lots of fluff to find that out. Then, what is the storage method and change scope? How do revision IDs work? No idea and I am not going to dig further. Final comment is that "100,000 files with 15,000 directories" isn't really that big. How many TB did that represent? How many revisions/branches/history?
- chipdart 2y ago
  > Interesting but this page reads like a marketing piece. I would go a step beyond and say that the page reads as if it was purposely designed to confuse the reader in order to hide the project's true features and capabilities, and instead create the baseless idea that it solves problems that it can't even state clearly. It reads like it's the zombo.com of VCSs. It's even more perplexing that it tries to portray itself as the next best thing, when it even fails to make a case on whether it even works at all.
albertzeyer 2y ago
> In Git, commit is an overloaded concept ... Grace simplifies this by breaking these usages out into their own gestures and events: ... To me, now having two different commands which I need to distinguish means actually some mental overhead. I need to think about, is this really ready now, or only partially ready? Often I don't really know. I keep rebasing and editing my history of commits until I think they are in a good shape, and then I publish (make a PR). grace promote seems easy to distinguish, if this is only intended for merges. Although I also don't see why it is such a problem to consider this also as a type of commit. Also, how are conflicts handled there? In Git, a commit always comes with a well defined state of the file tree, with one, or multiple parent commits (or also zero for the initial). > Every save is uploaded, automatically How does this handle files which are not yet tracked? Or all new files are automatically added? With Git, I always check first what files are added before I commit some new directory, to make sure I don't add files which don't belong into Git, like generated binaries or so. > You can fix [the merge conflict] while you're in flow, and skip the conflict later. To me, suddenly getting a merge conflict because of the background auto-rebase while working on some code sounds more like a distraction to get me out of the flow? > Personal branches, not forks So, you mean it's a centralized system? But does that mean, forks are not possible? Or when you fork, there are no good ways to work together anymore, e.g. merging branches from other forks? > Grace will have a native GUI app for Windows, Mac, Android, and iOS. (And probably Linux.) It sounds like Linux is not a priority now? This will turn off a lot of developers. I think for a new version control system, it makes more sense to have Linux as a priority, and Windows etc can come later.
- kelseydh 2y ago
  Yeah always tracking and uploading everything seems nice but brings with it security concerns. For example, if I generate a secret key or store a private keyfile into the repo before remembering to gitignore... err I mean graceignore it, then that key gets uploaded to the cloud. Oops. In Git these mistakes are more easily avoided as you are deliberate about what you commit and what stays local.
  - SBArbeit 2y ago
    > In Git these mistakes are more easily avoided as you are deliberate about what you commit and what stays local. And yet GitHub has built an entire security feature - Secret Scanning - because developers do not easily avoid checking in secrets. We have to face the fact that Git not being able to delete versions easily is a bug, not a feature, and that we do indeed sometimes need to delete versions from a repo. And so we've built a set of workarounds for Git to prevent pushes from succeeding when secrets have already been committed locally. It's not ideal. Grace will enable a combination of hoster-level Secret Scanning with a native ability to delete a version that you don't want. Imagine that you accidentally save a secret, it ends up in your personal branch as a Save reference, Secret Scanning catches it and prompts you about it: "A secret was detected. Should I delete that version for you?" No rewriting, no "hey Copilot how do I fix my repo after I committed a secret?", just one click and it's gone.
counterpartyrsk 2y ago
I don't need my boss to have access to every save I've made, and when I made it.
nathell 2y ago
> C'mon, it's 2024. There's got to be some AI in here, right? Wrong. This is a perfect way of convincing me _not_ to use the tool. I'd take dumb, dependable, predictable, easy-to-explain tools over "smart", "AI-enabled" ones any day. goes off to write a Dumb Software Manifesto
- gavinhoward 2y ago
  > goes off to write a Dumb Software Manifesto Please do! Or if you don't have time, I can do it. If so, I'd love to hear whatever thoughts you can throw into a quick reply.
  - tasuki 2y ago
    Not op, the more flattering word for "dumb" is "simple". Rich Hickey's talk "Simple made easy" had an impact on me.
    - gavinhoward 2y ago
      I agree with you, but in this specific context, we are talking about software without AI. I think "dumb" might be better.
cess11 2y ago
From the vision-list I understand that I'm not the target audience since I'm not afraid of my version control system, but I kind of think that maybe I'm also not unique in that I do a lot of swearing and insecure stuff and nasty tricks locally in the repo when I'm developing and it sort of seems like a really, really bad idea to stream it to a remote server...?
whoknowsidont 2y ago
There's a lot of salesy talk on the Github page and like zero examples of real world use and/or how it compares functionally to git. >Branch-level control of reference types Please. Do not encourage this. This is just begging to become a mess, especially in B2B .NET/Java shops that like to over complicate things. >Grace Server is designed to run on fast, cloud-based PaaS services for incredible scale and performance. Grace uses virtual actors as networked, in-memory data caches to maximize performance. What? Why? >Grace uses SignalR to create a live, two-way communication channel between client and server. Oh god NO. SignalR is a pain in the ass to manage. >When your parent branch gets updated, within seconds, grace watch will auto-rebase your branch on those changes, so you're always coding against the latest version that you'll have to promote to.When there is a problem, auto-rebase lets you find out right away. You can fix it while you're in flow, and skip the conflict later. This sounds nice. How does it handle merge conflicts? Where is an example here? Does it store the results of that merge resolution in case another update was pushed to the remote during that time?
- SBArbeit 2y ago
  > How does it handle merge conflicts? I'll use a simple example, with one `main` branch and however many child branches, like most repos. In Git, we merge to `main`. In effect, we take code from some other branch, and we shove it towards `main`, using a merge operation which sometimes results in code being created in `main` that's never existed in any other branch. This seems... odd. Even if we're used to it, it's just weird. Why would we want something in `main` that's never existed anywhere else, that's never been on a developers machine before, that's never been tested locally? So we build CI/CD pipelines and automated testing to check that code that's never been seen anywhere else and hope it's good. In Grace, changes move from `main` to the child branches through (auto-)rebase. There are no merges. The "merge" takes place during rebase, when changes from `main` are applied to the child branches. A promotion in Grace takes an already-existing version that's been committed to a branch, and simply creates a new reference to that root directory version in `main` that doesn't change any code at all. It's a simple database insert, actually. > Branch-level control of reference types Oh, hell yes. This is a great feature, actually. When `main` only allows Promotions and Tags, you're guaranteed that nothing gets to it without a promotion, which we can expect we'll have proper authorization controls for, and proper event-driven pre-checks with CI/CD, etc. No accidental "oops I pushed a secret and now everyone has to deal with rewriting history". Even if you push a secret to your branch, you can delete that save or checkpoint or even commit immediately. No harm, no foul. And the hosters will have something like GitHub's Secret Scanning to make sure that stuff doesn't end up in `main`. > SignalR Fortunately, you won't have to manage it. ;-) The hosters, like GitHub or GitLab, will manage it for you. Microsoft already has first-party services with hundreds of thousands of concurrent users on SignalR, I'm not worried about this at all.
beaugunderson 2y ago
I feel a visceral revulsion to this, especially: "Every save is uploaded, automatically". People are going to end up with so many credentials stored where they shouldn't be from local testing.
- SBArbeit 2y ago
  Things like GitHub's Secret Scanning will still be there to check... And if a secret ends up on your personal branch, you can delete the Save or Checkpoint or Commit and it'll disappear; no "rewrite history". Deleting versions is a native, expected use case in Grace. Git not being able to delete versions is a problem that's so bad that we've had to build massive systems (i.e. Secret Scanning) as a workaround. Grace, being built now, takes it for granted that versions need to disappear sometimes. In Grace, saves and checkpoints and, like Git, branches themselves, are ephemeral, they're meant to be created and deleted. Saves and checkpoints will be deleted automatically, with repo-level timeout settings.
  - idoubtit 2y ago
    > Things like GitHub's Secret Scanning will still be there to check... When a DVCS is successful, there are many server software. For git, there is the official git daemon and its wrappers (gitolite...), but also many forges, some of them having many local instances (Giltab, Gitea...). Grace should not depend on an optional (and error prone) feature of the server. > Git not being able to delete versions I don't understand. There is no concept of "version" in Git. You can delete commits, references and objects. For instance, you can delete/update a commit in your local branch. The old commit is still reachable, but you can run the garbage collector to delete it. You can also force a push that delete commits on a distant repository. As far as I know, the problem with deleting published secrets on public forges is that as soon as anything is published bots will copy it. And some of these bots are ill intentioned.
  - tasuki 2y ago
    It sounds incredibly complex. My guess is that it's going to end up a clusterfuck of everything and a kitchen sink built on ill-defined murky concepts with an easy UI bolted on top. Just the opposite of git. You don't seem to care much about simplicity, you care about shiny features.
snthpy 2y ago
Looks really interesting but I feel the README spends way to much time before getting to the point of how this differs from git. I would lead with the "Grace is an event sourced version control system ..." section.
acureau 2y ago
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. I don't think uploading on save is a wonderful idea for many reasons mentioned here. I don't agree with replacing forking with branching because forking is not only done to contribute to the mainline project. I'm against stuffing AI where solves no problem. I also get the feeling that if Grace goes anywhere it's going to be commercialized. It's practically screaming paid service.
- SBArbeit 2y ago
  > 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.
banish-m4 2y ago
It looks to me to be a continuous replication backup solution masquerading as a DVCS. Combining them is problematic in the real world because of local noise others don't need to see and of inadvertently committing secrets and temporary large files. The storage and networking demands for this would be enormous.
- SBArbeit 2y ago
  > inadvertently committing secrets Devs already do this all the time. That's why GitHub has Secret Scanning. The need for that kind of service doesn't change if the VCS changes. > temporary large files Saves in Grace are ephemeral, so those files will be deleted when the save references are deleted. There is a repo-level setting for how long that is, current default is seven days, but we'll see what makes sense. > The storage and networking demands for this would be enormous. Fortunately, Azure Blob Storage and AWS S3 and Google Cloud Storage are effectively infinite compared to any requirements from a version control system. I've only written the Azure Blob Storage implementation so far, but the idea is that Grace offloads all file upload/download traffic to those object storage services, using Azure SAS tokens [1] or AWS Presigned URL [2], etc. [1] https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview https://learn.microsoft.com/en-us/azure/storage/common/stora... [2] https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareO...
kursus 2y ago
Sounds like a marketing service had the idea to "simplify git", the presentation sounds like they haven't heard of git flows, and no offline mode is total no-go for me. > Think about this: if your Internet connection went down, could you continue to do your job Reads like "don't you guys have phones". My bet is it will be forgotten in a year.
- SBArbeit 2y ago
  > My bet is it will be forgotten in a year. How much? ;-)
globular-toast 2y ago
Aren't people using something like git-wip to commit changes to WIP branches every time they save? I've been doing it for years. The number of times I've gone to get something from those WIP branches: 0. Seriously. I keep it on "just in case", never needed it. Then again I do have a full tree-based undo system in my text editor.
bvrmn 2y ago
> Branching strategy is the thing about Grace that's most different from other version control systems. Because it's so different, it's worth going over it in some detail. > In single-step branching, each child branch can be promoted only to its parent branch, and must be based on the most-recent version in the parent before being allowed to be promoted. Um. Looks like it's a forced rebase with ff-merge. It's quite a stretch to call it "so different". Basically it locks you with a single server and prevents any decentralization. It's interesting how you solve consistency issues in cloud environment, this very invariant should not be violated.
bvrmn 2y ago
Looks like instead of VCS fear developers would get a code change fear. Because any mid to complex refactoring attempt would immediately break somebody's code after promotion.

137 points by davedx 2y ago

Not being able to work offline at all seems like somewhat of an issue. 99% of the time it's fine, but if you have even one thing you want to do locally, now you have to use two separate tools. I'm not sure how many people have an absolute hard requirement for local operation, but it is a nice extra layer of peace of mind. Git might not be perfect, but it's one of the only tools witch such a large market share. All your projects can use the same VCS, which is really nice. On the other hand, some programmers seem to really like having different highly specialized tools for every job, rather than adapting jobs to fit the tools, so I'm sure there's demand for a new VCS there.

gkhartman 2y ago
I don't develop offline often these days, but I do recall a recent time where my power went out for a few hours. Since I was using git on my laptop, I just shrugged and kept working. Using git allowed me to continue working in a flow state that would have normally been interrupted by a dropped connection. Of course, if your project doesn't run locally, that point is moot. For others, in areas with more power/connection interruptions, the time savef would add up.
- vandahm 2y ago
  I don't develop offline, but I've developed the habit of making lots of tiny commits, then rebasing them into a single commit before pushing. To me, a commit is for something I might want to undo and a push is for something that I either want to share or am afraid of losing. I'm not suggesting this is the best way to use version control or even a good way -- just that it's a habit I've developed and don't really want to unlearn.
kstrauser 2y ago
Almost all of us have that requirement sometimes. Working from a hotel coffee bar and the WiFi goes out? Bummer if that blocks your work. I’m online 98% of the time. My local tooling works 100% of the time. I’d want to defenestrate my laptop if it stopped working for a silly reason.
- riwsky 2y ago
  I don’t see how uninstalling Windows from your laptop is gonna solve hotel Wi-Fi problems—but power to you, I guess.
  - kstrauser 2y ago
    When you’re done with that, you can pitch it off the balcony.
- SBArbeit 2y ago
  > Working from a hotel coffee bar and the WiFi goes out? Bummer if that blocks your work. Grace doesn't change anything about that for you. You still write code locally, and `grace watch` will sync you up when you reconnect. You can't `git push` without an internet connection, either, and you can't work on your Azure / GCP / AWS resources. Or your Google Docs. Or your email. Or your Teams chat. Source control isn't a special case that must work offline, it's just that we're used to Git, and we pay the bad-UX tax of using a distributed VCS as a centralized VCS, because very few of us push to production from our dev boxes, only from a (Git)hub. Assuming a working internet connection in the late 2020's (i.e. roughly when Git will be replaced by some competitor) is not a blocker for almost every developer in the world. And Git will still be there if offline usage is a hard requirement.
  - eternityforest 2y ago
    Can you commit/checkpoint/branch offline?
  - thfuran 2y ago
    >in the late 2020's (i.e. roughly when Git will be replaced by some competitor) I'd put it at more like the late 2050s. I think it achieved critical mass. It certainly doesn't look like it's going anywhere in the next few years.
  - kstrauser 2y ago
    Hard disagree. It’s inherently true that I can’t work on remote servers and all those things but VCS are not inherently remote. I have entire local hobby projects I’ve never git pushed anywhere because my local copy is authoritative. We as an industry largely moved off centralized VCS because of those advantages of having 100% functionality on an airplane.
PontifexMinimus 2y ago
> Not being able to work offline at all seems like somewhat of an issue. I agree. If it's intended to be a web-based system, why not have it running as a webserver on your local machine? Also, the intention is to have a GUI, or rather 4 or 5 seeparate GUIs: > Grace will have a native GUI app for Windows, Mac, Android, and iOS. (And probably Linux.) But if you're having a web UI, why have a GUI as well? It is just extra work, and it is quite likely that the UI for these tools won't be the same, potentially making them harder to learn.
- SBArbeit 2y ago
  The intention is that they'll be identical, because they'll be written using Avalonia. And I hate Electron. I hate it so much. I hate the web pages that I'm being told are "apps". I hate the lack of keyboard shortcut support. I hate the bad performance. I hate how it's not stick-to-your-finger fast. I hate owning unbelievably powerful computers and mobile devices and not taking advantage of their power and capabilities, and just reducing them to surfaces for fake "apps". I refuse to not deliver native apps with Grace.
  - kstrauser 2y ago
    This we can agree on. Thanks for making that a design goal!
  - PontifexMinimus 2y ago
    > And I hate Electron I'm not a fan of it either. When I say have a web UI, I don't mean electron, I mean the program runs as a web server on some port your local machine and you point you web browser at it. I don't think electron should exist. > I hate the lack of keyboard shortcut support And I hate the existence of keyboard shortcuts, or at least hard-to-discover ones. On a daily basis I accidentally press keys (I've no idea which ones) that make my windows misbehave. I also don't think I should have to learn keyboard shortcuts -- interfaces should be discoverable and not require you to memorise stuff. > I hate the bad performance. Then use a text UI not a GUI. Back in the day, Borland made extensive use of these for Turbo Pascal and they worked well and looked good. As a bonus (like a web app) they can run easily on an external machine. > I hate how it's not stick-to-your-finger fast. I've used git for years and before it other source control systems. I don't remember a single instance where the slowness of the source control system was ever a factor.

gavinhoward 2y ago

Well, shoot. I am working on a new VCS too, and Grace seems to have most of what I want in mine. The only two things mine might do better are large binary files (because I do think they belong in version control) and decentralization.

lagniappe 2y ago
> The only two things mine might do better are large binary files (because I do think they belong in version control) Alright you got me, I'm listening
- gavinhoward 2y ago
  Ah, didn't expect interest. I want to track changes to binary files the way we do with text. [1] For example, if you have a PNG texture, my VCS will track changes at the pixel level. If you have a Blender file, it will track changes at the item level, from meshes to materials and vertices, and everything in-between. Yes, it will be a lot of manual work to implement each file type, but that's how I plan to make money. [1]: Only files that use lossless compression, of course.
  - albertzeyer 2y ago
    Interesting idea. I assume with quite a number of technical difficulties (even despite the manual work for each file type). However, I don't think making money from this will work. A new version control system must be 100% open source. Otherwise it will not be an option for most people. Even when only selling extensions for certain file types and keeping the core open source, I don't think this will work, as you keep away the main interesting feature then.
    - gavinhoward 2y ago
      FWIW, I think you are absolutely right. However, my target audience isn't developers; my target is users of Perforce, which is closed source. So I think a source available [1] VCS will be palatable for that audience. I could be wrong, though. [1]: https://gavinhoward.com/2023/12/is-source-available-really-that-bad/ https://gavinhoward.com/2023/12/is-source-available-really-t...

calvinmorrison 2y ago

I am sorry, maybe I am a boomer but I don't like it one bit. > Grace is a new, modern, cloud-native version control system. The whole point of git was to replace crappy centralized solutions > Grace Server scales up by running on Kubernetes and massive PaaS services from large cloud providers. word salad > Every save is uploaded, automatically Can't wait for the passwords to start leaking. Grace simplifies this by breaking these usages out into their own gestures and events: > grace checkpoint - this means "I'm partially done", for you to keep track of your own progress > grace commit - this is "I'm really done" or "This version is a candidate for promotion"; you'd use a commit for a PR > grace promote - in Grace, promotions replace merges; a promotion is how Grace moves code from a child branch to a parent branch I have no problem with this, I even like it. Some around here will remember before "MRs", well then called "PRs" were ubiquitous, Git can provide different workflows. We can write tools on top of git, like github, to do more fancy things. I think it's high time for some new concepts backed by git > When your parent branch gets updated, within seconds, grace watch will auto-rebase your branch on those changes, so you're always coding against the latest version that you'll have to promote to. I don't think I ever wanted to auto rebase on every time I save. In fact, I think I really don't like this... in fact, we might as well just all start co-editing on the same server > Personal branches, not forks > With Grace, there's no need for forking entire repositories just to make contributions. In open-source repos, you'll just create a personal branch against the repo. This is what everyone does normally, except Github made forks a thing or whatever so you could clone someone elses repo and hack on it without having mainline permissions.

chrisallenlane 2y ago
> Personal branches, not forks > With Grace, there's no need for forking entire repositories just to make contributions. In open-source repos, you'll just create a personal branch against the repo. > This is what everyone does normally, except Github made forks a thing or whatever so you could clone someone elses repo and hack on it without having mainline permissions. Yeah. I'm an open-source maintainer and the "everyone creates a branch on upstream" model is a complete non-starter for me, even if only due to the mess it would cause. This is a massive step backward from "fork and pull."

krick 2y ago

Honestly cannot tell at the first glance if it's a joke. "Welcome to Grace" feels like it obviously must be a joke. But then it's kinda too elaborate for a joke (and not very original one too). So…?

khazhoux 2y ago
You're really gonna have to fill the rest of us in on what could possibly be joke-like about the throwaway intro line "Welcome to Grace." And "not very original" makes it sound like in your world, "Welcome to Grace" is a common joke of sorts. ??

ilc 2y ago

The centralization and also the monitoring are hard nopes for me. If the monitoring was all local and not pushed up to k8s instantly, maybe. But this screams of a PHB's wet dream. As someone who has maintained forks of large FOSS code bases. This also makes doing that harder. I wasn't interested in sharing my changes. But I wanted SCM to allow me to merge upstream's changes. This feels like a step back to systems like Clearcase, and I.. Just don't want it.

deepsun 2y ago
PHB -- do you mean Portland Housing Bureau, Pedestrian Hybrid Beacons or Polyhydroxybutyrate?
- voidfunc 2y ago
  Pointy Haired Boss... Dilbert... Ugh now I feel old and I'm only in my 30s.
- minasmorath 2y ago
  Player's Handbook.
- ilc 2y ago
  Pointy Haired Boss. I now feel very old. Dilbert taught engineers how the world worked in a sarcastic over the top way. No wonder new engineers are confused :(
deleted 2y ago
[deleted]

samatman 2y ago

It appears that this solves exactly no problems which I have, while introducing a slew of problems I don't have currently and am grateful not to. I know this comment risks falling to the low-brow dismissal bucket, but it's hard for me to say anything more cogent than that. It all seems so obvious? Like, Kubernetes, your choice of cloud provider, "who works offline anyway"... No thanks.

deleted 2y ago
[deleted]

vouaobrasil 2y ago

Random thought, but I used to use version control (Git) for work. After I quit, I kept programming for fun...and to be honest I like programming without version control a lot better. I realized I hate version control. It imposes too much structure on programming, like having to keep all my drafts of the past. It's rather stifling in fact. Now, I know version control is super useful for large projects, especially of the commercial variety. But now I see all the modern software out there and I wonder if maybe the increasingly commercialization of the software world has in part been accelerated by version control, which makes programming more robotic and less artistic.

metadat 2y ago
I find git freeing and empowering, because I never have to worry about FOMO - I can rewind or pull up any past checkpoint.
000ooo000 2y ago
Interesting perspective. I feel the opposite; in my personal projects, I love having Git because I can fearlessly rework things knowing I can just abandon the rework if it's not playing out, or stick the rework in a branch and come back to it later. Different strokes!
- vouaobrasil 2y ago
  True enough! I like the lack of version control because it feels like surviving in the wilderness with less safety gear and more self-reliance, or swimming in a lake without a life guard.
  - snthpy 2y ago
    I guess people like soloing big walls of rock so if it works for you. My risk appetite is a lot lower and I try to use version control for everything.
thfuran 2y ago
>I realized I hate version control. It imposes too much structure on programming, Having used several different VCS, I have no idea what you're talking about. Are you conflating some complex CI/CD setup with branch naming schemes and oodles of hooks with version control in general? I mean, I think git is slightly overly opinionated when it comes to the relationship between commits and branches, but I don't get the impression that is what you mean.

kstrauser 2y ago

> Because grace watch automatically uploads new file versions after every save, … Nope. I type stuff all the time that I don’t want anyone else seeing. # I hate this ^#{=+ thing just work dammit Or password = ‘foo’ # TK fetch this from disk later Etc. I don’t want my computer sharing my scratch notes with my coworkers without me explicitly choosing to commit and push them. No way, no how. (Also the presumption of always online-dness. What?)

SBArbeit 2y ago
You can use Grace without running `grace watch`, but really it's a much better experience if you do. It makes version control more ambient, more something that just happens in the background. And you can delete any save or checkpoint that you don't want, it'll disappear. I mean, I assume you don't type curse words every time you edit a file. I don't... it's only like every 10 edits or so for me. ;-) Yes, I presume that almost every developer in the world, by the late 2020's, will have a working Internet connection ~100% of the time. If you still need some sort of offline VCS, Git will still be around. Treating source control as something that must work without an internet connection is just silly to me... we almost all use Git as a centralized version control system already. You can't push without an Internet connection, and most dev shops won't let you push to production without going through the (Git)hub first. It's not like Grace will prevent you from making changes; as soon as you have a connection again, `grace watch` will catch you up. Or don't use that and just do `grace rebase` or whatever. Up to you.

kstenerud 2y ago

> Every save is uploaded, automatically Nope. Last thing I want is for my repo to become huge just because I happened to temporarily create a big file inside the repository directory. Or passwords and credentials to leak because I needed to do a test run. I can see it now: A new kind of malware that repo bombs your organization by randomly creating 2TB files in some guy's repos. Every single person becomes the potential point of network collapse. > every save and commit, every branch name change, every everything, is stored as a separate event. Why would you DO that??? Every branch name change??? That's OCD level crazy. > Imagine: there's a promotion to main, your branch gets auto-rebased on those latest changes, and then your local unit test suite gets run automatically so you immediately know if there's a problem. Oh my god NO!!! The last thing I want is a ghost in the machine changing stuff while I'm working on my branch! Imagine the function you're working on changing mid-edit due to a rebase! What hell is being unleashed here? > Grace lets you share your code with team members effortlessly, around the world, for those times when you need another set of eyes on it, or just want to show them something cool. You can already do that! It's called a branch. > C'mon, it's 2024. There's got to be some AI in here, right? OMG Seriously??? > No stashing Okay, now you're just taking the piss... By this point I'm checking to see if it's April 1st.

rigelbm 2y ago
Imagine you did have an idea, put a lot of effort building it, just so that some random person takes a dump on your work. It wouldn't be nice, would it? Unnecessarily harsh and misses the point that this is a new VCS that brings valid new ideas to table. As with any new thing, if it's not for you, it's not for you. SBArbeit, ignore this kind of comment. Not because it's not valid feedback, but because it isn't worth it.
- SBArbeit 2y ago
  Thank you. <3 I do ignore them. There's no way to build something with an intention as big as "replace Git" that won't invite knee-jerk reactions. I know I'm building the thing that aligns with my creative and technical vision. That's all I can do. It will succeed or it won't, and the reactions from people who are already super-comfortable with the existing technology matter less than the reactions from people who only understand the basics of Git and are afraid of it. I'm building it for them (which includes me).

senkora 2y ago

> AI to help resolve conflicts This does actually sound quite helpful, if your workflow involves frequent merges (and I feel for you if it does). I know that git has configurable merge strategies; has anyone written one that calls out to AI? https://git-scm.com/docs/merge-strategies https://git-scm.com/docs/merge-strategies

bigfishrunning 2y ago
I imagine it's like AI code generation: the work required to review the merge is very likely more then the work required to implement the merge.
karpovv-boris 2y ago
I guess marketing win if we're talking about ai (which is ML!) in context of some obvious and deterministic operation as merge. (go see rerere https://git-scm.com/docs/git-rerere https://git-scm.com/docs/git-rerere)
SBArbeit 2y ago
A big design driver for Grace is eliminating fear around using version control. Merge conflicts are one of the big places where fear can happen, even if it's subtle; you think you're all done with your work and then... ugh, what happened? are my changes stepping on the other changes? are they stepping on mine? do I have to retest? etc. Having an event-driven, automatic AI review of a conflict is just something that makes sense today. I don't just want to tell you there's a conflict, I want to tell you there's a conflict and give you a solution to it that you can accept with one click if it looks good. Grace will even be able to run CI/CD pipelines against that proposed resolution before it tells you about it to help you make the decision.
- acureau 2y ago
  I'm not sure how that makes sense today, to me it's more of a novel idea than a solution to a problem. I use AI every day in my workflow and I honestly don't believe it's capable of reliably solving merge conflicts. GPT-4 can write a really nice method but can't integrate it into my code-base. If half of the proposed solutions are incorrect, I need to scrutinize all proposed solutions equally. Would I rather review likely inaccurate conflict resolutions, only to solve it myself afterwards, or resolve it myself from the get-go in a way that I know makes sense? Do I want to give my teammates the ability to click a button and introduce subtle merge bugs?

fredsmith219 2y ago

Does anybody else see the irony of storing a new version control system on GitHub?

SBArbeit 2y ago
It's an interesting problem, right? First, Grace is still an alpha, and isn't ready to be trusted for real yet. Too much work left to do, and so far it's just me. Second, as I open up to contributors, we need a place to work together. GitHub is the Home of Open Source. It's not just about the version control system; it's about the social network and features built around it, and right now GitHub has all of the other features, and I don't have time to build Repos, Issues, Discussions, PR's, Actions, and the rest of what GitHub has in addition to a VCS. At some point, I will run Grace's version control in Grace, and create a way to use GitHub Actions to automate things from there, while keeping Issues, PR's, Actions, etc. somehow in GitHub. It's a ways off, for sure.

mberning 2y ago

So now I need kubernetes to run and scale my vcs? That’s a no for me dawg.

CharlieDigital 2y ago

Did not expect to see F# and C#; pleasantly surprised.

howtoagi 2y ago
[dead]
junto 2y ago
I also noticed that. 95% F# too.
SBArbeit 2y ago
I'm a long-time C# dev who got into F# about five years ago. F# is so awesome, I hope that if Grace catches on, that more people will pay some attention to it. And .NET is so fast. No-brainer.

SBArbeit 2y ago

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?

TulliusCicero 2y ago

I like the idea of it being easy to use. I can get by with git and mercurial, but I find that occasionally I fuck things up and don't really know how to fix it other than manually copying some files around and blowing away a branch. A lot of the error messages just feel obtuse.

deleted 2y ago
[deleted]

gwbas1c 2y ago

IMO: 1: Lead with the most critical differentiators versus git. Source control systems are a dime-a-dozen. The "I can do this better" projects that fail are a dime-a-dozen. Get us hooked within the first 3 paragraphs. 2: I personally don't (usually) encounter performance issues with git. I get more from Visual Studio than git. The only performance issue are the random garbage collections, and those are infrequent. > When your parent branch gets updated, within seconds, grace watch will auto-rebase your branch on those changes 3: Automatically changing my code while I am working on it is a horrible idea. DO NOT DO THIS. Often, programming requires low distractions, and the distraction of changing the very thing that I am working on while I am working on it is a huge distraction. The dangers: - If I am trying to isolate a specific behavior, auto-rebase could change the behavior of what I'm trying to isolate while I'm trying to isolate it. - If the upstream rebase creates a build error, it will completely destroy my flow. (It makes me stop a task while I am incomplete.) This could happen if the parent branch has a renamed method, and my changes introduce a new call to that method. Instead, I suggest a very gentle notification about parent branch updates. Don't steal focus. Edit: I was lead developer on a desktop file sync client for 9 years. Whenever I had a support escalation from someone using us as source code control, I'd always recommend that the customer use git and tell them that we used Github. Source code repositories have A LOT of transient files that come and go very quickly, and are very hard on live file sync.

deleted 2y ago
[deleted]

howtoagi 2y ago

[dead]

pluto_modadic 2y ago

I guess I wouldn't use the "watch" command. ever. no thanks.

deleted 2y ago

[deleted]

okaleniuk 2y ago

I think, this is a step forward. I got used to real-time version tracking when I was working on a book. The publisher insisted that the working files are kept in the Box folder (like a DropBox, or any other cloud-shmoud synchronized storage). This was... convenient and practical. This way of working is much better than the Git way if you work alone and produce dozens or hundreds of meaningful changes a day. But at some point you have to publish. You have to make sure your state is correct to some level of certainty, and share it with other people. So you still need some kind of 'commit' thingie. I think, Grace gets this both ways right. Personally, I just keep GitHub repos in a DropBox folder, but if Grace catches on, I might consider hoping in.

SBArbeit 2y ago
Thank you. One of the original, first-night-dreaming-about-it inspirations for Grace was the OneDrive sync client; since they rewrote it back in like 2018 or whatever it's been so rock-solid, and it's ambient. I wanted that experience for version control; make as much happen in the background as possible, and make it fast when you need to interact with it.
- tichiian 2y ago
  OneDrive sync and "rock-solid" in the same sentence? I beg to differ. Frequent conflicts due to non-synced files, the client crashing, randomly failing auth, files that are indicated to be recent and in sync but really aren't, no proper debuggability, no insight into why things don't work if they (frequently) don't. I could go on. OneDrive is a very bad thing to reference in this context.
  - SBArbeit 2y ago
    That hasn't been my experience for at least six years. I think I've had one weird sync issue with OneDrive, like a couple of years ago... I forget, but it just works, across all of my computers, in near-real-time.
IshKebab 2y ago
I think probably the big difference is "if you work alone". You have to go to extra effort with Git because you need your changes to be understandable and usable by other people. I dunno if this is the right thing for team based coding projects. I think we just need something like Git with: * A saner CLI * Proper support for large files * Proper support for submodules * Better conflict resolution I think Pijul goes some way towards some of those, especially the last one, and maybe submodules.

2d8a875f-39a2-4 2y ago

Interesting but this page reads like a marketing piece. The discourse around VCSs is mature and you should BLUF with where yours sits in the spectrum of alternatives. What is the repository model and the concurrency model? Those are the basics. Seems to be centralized & um, merge or lock, maybe? I don't want to have to parse lots of fluff to find that out. Then, what is the storage method and change scope? How do revision IDs work? No idea and I am not going to dig further. Final comment is that "100,000 files with 15,000 directories" isn't really that big. How many TB did that represent? How many revisions/branches/history?

chipdart 2y ago
> Interesting but this page reads like a marketing piece. I would go a step beyond and say that the page reads as if it was purposely designed to confuse the reader in order to hide the project's true features and capabilities, and instead create the baseless idea that it solves problems that it can't even state clearly. It reads like it's the zombo.com of VCSs. It's even more perplexing that it tries to portray itself as the next best thing, when it even fails to make a case on whether it even works at all.

albertzeyer 2y ago

> In Git, commit is an overloaded concept ... Grace simplifies this by breaking these usages out into their own gestures and events: ... To me, now having two different commands which I need to distinguish means actually some mental overhead. I need to think about, is this really ready now, or only partially ready? Often I don't really know. I keep rebasing and editing my history of commits until I think they are in a good shape, and then I publish (make a PR). grace promote seems easy to distinguish, if this is only intended for merges. Although I also don't see why it is such a problem to consider this also as a type of commit. Also, how are conflicts handled there? In Git, a commit always comes with a well defined state of the file tree, with one, or multiple parent commits (or also zero for the initial). > Every save is uploaded, automatically How does this handle files which are not yet tracked? Or all new files are automatically added? With Git, I always check first what files are added before I commit some new directory, to make sure I don't add files which don't belong into Git, like generated binaries or so. > You can fix [the merge conflict] while you're in flow, and skip the conflict later. To me, suddenly getting a merge conflict because of the background auto-rebase while working on some code sounds more like a distraction to get me out of the flow? > Personal branches, not forks So, you mean it's a centralized system? But does that mean, forks are not possible? Or when you fork, there are no good ways to work together anymore, e.g. merging branches from other forks? > Grace will have a native GUI app for Windows, Mac, Android, and iOS. (And probably Linux.) It sounds like Linux is not a priority now? This will turn off a lot of developers. I think for a new version control system, it makes more sense to have Linux as a priority, and Windows etc can come later.

kelseydh 2y ago
Yeah always tracking and uploading everything seems nice but brings with it security concerns. For example, if I generate a secret key or store a private keyfile into the repo before remembering to gitignore... err I mean graceignore it, then that key gets uploaded to the cloud. Oops. In Git these mistakes are more easily avoided as you are deliberate about what you commit and what stays local.
- SBArbeit 2y ago
  > In Git these mistakes are more easily avoided as you are deliberate about what you commit and what stays local. And yet GitHub has built an entire security feature - Secret Scanning - because developers do not easily avoid checking in secrets. We have to face the fact that Git not being able to delete versions easily is a bug, not a feature, and that we do indeed sometimes need to delete versions from a repo. And so we've built a set of workarounds for Git to prevent pushes from succeeding when secrets have already been committed locally. It's not ideal. Grace will enable a combination of hoster-level Secret Scanning with a native ability to delete a version that you don't want. Imagine that you accidentally save a secret, it ends up in your personal branch as a Save reference, Secret Scanning catches it and prompts you about it: "A secret was detected. Should I delete that version for you?" No rewriting, no "hey Copilot how do I fix my repo after I committed a secret?", just one click and it's gone.

counterpartyrsk 2y ago

I don't need my boss to have access to every save I've made, and when I made it.

nathell 2y ago

> C'mon, it's 2024. There's got to be some AI in here, right? Wrong. This is a perfect way of convincing me _not_ to use the tool. I'd take dumb, dependable, predictable, easy-to-explain tools over "smart", "AI-enabled" ones any day. goes off to write a Dumb Software Manifesto

gavinhoward 2y ago
> goes off to write a Dumb Software Manifesto Please do! Or if you don't have time, I can do it. If so, I'd love to hear whatever thoughts you can throw into a quick reply.
- tasuki 2y ago
  Not op, the more flattering word for "dumb" is "simple". Rich Hickey's talk "Simple made easy" had an impact on me.
  - gavinhoward 2y ago
    I agree with you, but in this specific context, we are talking about software without AI. I think "dumb" might be better.

cess11 2y ago

From the vision-list I understand that I'm not the target audience since I'm not afraid of my version control system, but I kind of think that maybe I'm also not unique in that I do a lot of swearing and insecure stuff and nasty tricks locally in the repo when I'm developing and it sort of seems like a really, really bad idea to stream it to a remote server...?

whoknowsidont 2y ago

There's a lot of salesy talk on the Github page and like zero examples of real world use and/or how it compares functionally to git. >Branch-level control of reference types Please. Do not encourage this. This is just begging to become a mess, especially in B2B .NET/Java shops that like to over complicate things. >Grace Server is designed to run on fast, cloud-based PaaS services for incredible scale and performance. Grace uses virtual actors as networked, in-memory data caches to maximize performance. What? Why? >Grace uses SignalR to create a live, two-way communication channel between client and server. Oh god NO. SignalR is a pain in the ass to manage. >When your parent branch gets updated, within seconds, grace watch will auto-rebase your branch on those changes, so you're always coding against the latest version that you'll have to promote to.When there is a problem, auto-rebase lets you find out right away. You can fix it while you're in flow, and skip the conflict later. This sounds nice. How does it handle merge conflicts? Where is an example here? Does it store the results of that merge resolution in case another update was pushed to the remote during that time?

SBArbeit 2y ago
> How does it handle merge conflicts? I'll use a simple example, with one `main` branch and however many child branches, like most repos. In Git, we merge to `main`. In effect, we take code from some other branch, and we shove it towards `main`, using a merge operation which sometimes results in code being created in `main` that's never existed in any other branch. This seems... odd. Even if we're used to it, it's just weird. Why would we want something in `main` that's never existed anywhere else, that's never been on a developers machine before, that's never been tested locally? So we build CI/CD pipelines and automated testing to check that code that's never been seen anywhere else and hope it's good. In Grace, changes move from `main` to the child branches through (auto-)rebase. There are no merges. The "merge" takes place during rebase, when changes from `main` are applied to the child branches. A promotion in Grace takes an already-existing version that's been committed to a branch, and simply creates a new reference to that root directory version in `main` that doesn't change any code at all. It's a simple database insert, actually. > Branch-level control of reference types Oh, hell yes. This is a great feature, actually. When `main` only allows Promotions and Tags, you're guaranteed that nothing gets to it without a promotion, which we can expect we'll have proper authorization controls for, and proper event-driven pre-checks with CI/CD, etc. No accidental "oops I pushed a secret and now everyone has to deal with rewriting history". Even if you push a secret to your branch, you can delete that save or checkpoint or even commit immediately. No harm, no foul. And the hosters will have something like GitHub's Secret Scanning to make sure that stuff doesn't end up in `main`. > SignalR Fortunately, you won't have to manage it. ;-) The hosters, like GitHub or GitLab, will manage it for you. Microsoft already has first-party services with hundreds of thousands of concurrent users on SignalR, I'm not worried about this at all.

beaugunderson 2y ago

I feel a visceral revulsion to this, especially: "Every save is uploaded, automatically". People are going to end up with so many credentials stored where they shouldn't be from local testing.

SBArbeit 2y ago
Things like GitHub's Secret Scanning will still be there to check... And if a secret ends up on your personal branch, you can delete the Save or Checkpoint or Commit and it'll disappear; no "rewrite history". Deleting versions is a native, expected use case in Grace. Git not being able to delete versions is a problem that's so bad that we've had to build massive systems (i.e. Secret Scanning) as a workaround. Grace, being built now, takes it for granted that versions need to disappear sometimes. In Grace, saves and checkpoints and, like Git, branches themselves, are ephemeral, they're meant to be created and deleted. Saves and checkpoints will be deleted automatically, with repo-level timeout settings.
- idoubtit 2y ago
  > Things like GitHub's Secret Scanning will still be there to check... When a DVCS is successful, there are many server software. For git, there is the official git daemon and its wrappers (gitolite...), but also many forges, some of them having many local instances (Giltab, Gitea...). Grace should not depend on an optional (and error prone) feature of the server. > Git not being able to delete versions I don't understand. There is no concept of "version" in Git. You can delete commits, references and objects. For instance, you can delete/update a commit in your local branch. The old commit is still reachable, but you can run the garbage collector to delete it. You can also force a push that delete commits on a distant repository. As far as I know, the problem with deleting published secrets on public forges is that as soon as anything is published bots will copy it. And some of these bots are ill intentioned.
- tasuki 2y ago
  It sounds incredibly complex. My guess is that it's going to end up a clusterfuck of everything and a kitchen sink built on ill-defined murky concepts with an easy UI bolted on top. Just the opposite of git. You don't seem to care much about simplicity, you care about shiny features.

snthpy 2y ago

Looks really interesting but I feel the README spends way to much time before getting to the point of how this differs from git. I would lead with the "Grace is an event sourced version control system ..." section.

acureau 2y ago

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. I don't think uploading on save is a wonderful idea for many reasons mentioned here. I don't agree with replacing forking with branching because forking is not only done to contribute to the mainline project. I'm against stuffing AI where solves no problem. I also get the feeling that if Grace goes anywhere it's going to be commercialized. It's practically screaming paid service.

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

banish-m4 2y ago

It looks to me to be a continuous replication backup solution masquerading as a DVCS. Combining them is problematic in the real world because of local noise others don't need to see and of inadvertently committing secrets and temporary large files. The storage and networking demands for this would be enormous.

SBArbeit 2y ago
> inadvertently committing secrets Devs already do this all the time. That's why GitHub has Secret Scanning. The need for that kind of service doesn't change if the VCS changes. > temporary large files Saves in Grace are ephemeral, so those files will be deleted when the save references are deleted. There is a repo-level setting for how long that is, current default is seven days, but we'll see what makes sense. > The storage and networking demands for this would be enormous. Fortunately, Azure Blob Storage and AWS S3 and Google Cloud Storage are effectively infinite compared to any requirements from a version control system. I've only written the Azure Blob Storage implementation so far, but the idea is that Grace offloads all file upload/download traffic to those object storage services, using Azure SAS tokens [1] or AWS Presigned URL [2], etc. [1] https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview https://learn.microsoft.com/en-us/azure/storage/common/stora... [2] https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareO...

kursus 2y ago

Sounds like a marketing service had the idea to "simplify git", the presentation sounds like they haven't heard of git flows, and no offline mode is total no-go for me. > Think about this: if your Internet connection went down, could you continue to do your job Reads like "don't you guys have phones". My bet is it will be forgotten in a year.

SBArbeit 2y ago
> My bet is it will be forgotten in a year. How much? ;-)

globular-toast 2y ago

Aren't people using something like git-wip to commit changes to WIP branches every time they save? I've been doing it for years. The number of times I've gone to get something from those WIP branches: 0. Seriously. I keep it on "just in case", never needed it. Then again I do have a full tree-based undo system in my text editor.

bvrmn 2y ago

> Branching strategy is the thing about Grace that's most different from other version control systems. Because it's so different, it's worth going over it in some detail. > In single-step branching, each child branch can be promoted only to its parent branch, and must be based on the most-recent version in the parent before being allowed to be promoted. Um. Looks like it's a forced rebase with ff-merge. It's quite a stretch to call it "so different". Basically it locks you with a single server and prevents any decentralization. It's interesting how you solve consistency issues in cloud environment, this very invariant should not be violated.

bvrmn 2y ago

Looks like instead of VCS fear developers would get a code change fear. Because any mid to complex refactoring attempt would immediately break somebody's code after promotion.