SBArbeit

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

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.

> I think we just need something like Git with:

There have been lots of projects over the last 10+ years that have been riffs on "It's Git, but <better in this way>", but none of them have really caught on beyond a small, admittedly passionate group.

I believe that's because once you go through the pain of learning Git, the idea of learning yet another distributed version control system or client seems so unappealing to most people that they'll never do it.

The truth is: if you're using GitHub or GitLab or some other hoster, you're already doing centralized version control; you're just doing it with a confusing distributed version control UX. I'm just trying to skip to the part where we just admit it and call it centralized and build something that makes that experience awesome.

When small trends change quickly - like, jQuery -> Ember -> Aurelia -> Angular -> React - the differences between them can be small.

When major trends change slowly, over decades - like relational -> map-reduce -> key-value -> document db -> graph db - the differences between them are usually much greater, and even if an older product adopts some piece of doing it the new way (think, SQL Server supports JSON storage well enough, but really you want to use a Document DB for that) it's a bolt-on or it doesn't quite fit with the design intent of the system.

Replacing Git is one of those large trend changes, and I don't believe that any "Git, but <better>" product will ever make that change happen. I think it's time for something really different, and a pendulum swing back to centralized, but with modern, fast cloud-native features and infrastructure, ready for high-scale monorepos and large file storage and effectively infinite repo sizes is the way to go.

I don't think there's a good, not-confusing way to build a distributed version control system. Others disagree, that's cool, and there are other wonderful version control projects like Pijul [1] and jj [2] and JamHub [3] and others who are trying to make a better distributed VCS. I know some of the people working on those projects, they're awesome, they care about doing it well, and I wish them all the luck in the world.

Something will catch on and replace Git, soon. Grace is my offering to that.

[1] https://pijul.org/ [2] https://github.com/martinvonz/jj [3] https://jamhub.dev/

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

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.

> I'd like to start by congratulating though, this is no small feat!

First of all, thank you. <3 It's been a journey, and it's only going faster. I'm more proud of Grace than anything I've ever written. And thanks for the long comment.

> Many people before me have already pointed out many of the pain points

Many people have reacted based on years of Git brainwashing, yes. :-) The people commenting here are usually the ones who deeply understand Git and wonder why other people don't and "what's the problem?" My experience in the last couple of years is that the reactions from that crowd have been mostly negative because they don't feel the pain that the other 80% or so of devs feel.

It's not unlike any other new technology. For example, SQL Server expert: "Why do we need a document database? SQL Server does what we need! This is a waste of time, just use SQL Server correctly!" Service Fabric expert: "Why do we need Kubernetes? Service Fabric does what we need! This is a waste of time, just use Service Fabric correct!" C++ expert: "Why to we need Rust? C++ does what we need! This is a waste of time, just use C++ correctly!"

It's like that.

Git has terrible UX, but it's the pain we know, and the workarounds that we're used to that we don't realize anymore are workarounds. Git is not the final word in version control, and we deserve better. There are other, much better ways to do things. Really.

> As a few already said, uploading every keystroke seems madness to me.

I never said "upload after every keystroke". Grace has no idea that you've typed anything - it's all user-mode, my days of writing Windows kernel-mode hooks are long since past. lol And I've never written a keystoke logger! eww...

It does use a file system watcher, so it knows when files in the directory you're tracking (i.e. the one with a .grace directory) have changed.

Right now, there's no explicit `grace add` like there's a `git add`. There's just a .graceignore file. I find Git's need for an explicit add gesture to be bad UX; again, it's UX that most have gotten used to, but that doesn't mean it's right. If enough people really want add to be explicit, we'll make it work but probably not make it the default behavior.

The only time auto-rebase happens is when the parent branch of your branch gets updated. We can all expect that, like GitHub has today with pre-receive hooks and Secret Scanning, that your files will be scanned for secrets and handled appropriately. The different for Grace is: deleting a version that you don't want is an expected, normal function, unlike rewriting Git history and hoping that everyone else sharing the repo does their fetches and rebases and whatever appropriately to remove the unwanted version.

> could I change provider if I wanted to?

I haven't written that level of import/export yet, but it'll have to exist at some point. Changing hosters is a rare, once-in-a-few-years-if-ever event for most organizations and most individuals, because it's not just about the code, it's about the CI/CD and packages and issues and PR's and project tracking.

> Backups now seem a fairly complicated ordeal.

Yes and no. I'll offer a backup in `git bundle` format, so that's simple. I have no intention of writing a live Git-to-Grace sync, the branching model is different enough that the corner cases would be hard to deal with.

On the server side, yes, like every other cloud-native system that uses more than one data service, backups will need to be coordinated. I've written a short paper on that [1].

> The only environment in which I see this being a possibly reasonable choice is an enterprise one.

Hard disagree. Enterprise is definitely a main target for Grace, but there's no replacing of Git without making life better for open-source devs as well, and Grace is meant for them/us. Personal branches on open-source projects, not forks, plus auto-rebase that keeps your personal branch up-to-date with `main` instead of walking up to a fork after weeks or months and seeing `234 commits behind` and declaring bankruptcy... until you actually use it, it might be hard to see how nice auto-rebase is, but, really, it changes how you feel about how clunky and manual and disconnected Git is.

Giving developers a different, much better UX is enough reason for open-source to adopt it, but when you see how fluid and connected it becomes to work together in open-source with Grace I expect it'll catch on.

> what is the future that you forsee for Grace? How would you spread its adoption without individual developers using it?

Short version:

Git is reaching it's EOL, for a few reasons. Grace is intended to be ready to meet the actual needs of developers in the late 2020's, not the mid-2000's like Git. Individual developers will use it. And the UX is so much better once you try it that it won't be a hard sell for most.

Longer version:

Git, as used today by most everyone, is a centralized version control system, that we access through a confusing distributed version control UX. Unless you push to production from your dev box, you're only shipping code by running `git push` and seeing that code run through some centralized CI/CD pipelines. This is one indication that the use case for Git, and the design of Git, have diverged enough to look like it's time for something new to come.

We all have to come to terms with the fact that we've found Git's fundamental design limits. As monorepos have come into fashion - and if we do nothing else in this industry, we follow fashion trends - we're seeing more and more that the only way to do large monorepos well is to use `git scalar` and partial clones so we don't clog our machines and Git servers with unnecessary traffic.

Once you're using `git scalar`, you're explicitly using Git as a centralized version control system, to run a repo that's centralized on a hoster, and the size of those repos forces GitHub and GitLab etc. to constantly invest in how to scale up the server side to match customer demands. Don't forget, the hosters all run Git protocol, but how they store data behind that protocol is the secret sauce of taking a mid-2000's client/server thing like Git and making it web-scale, and the demands on that scaling are only going up.

So, we've broken the client-side contract of Git - Git has the full repo on every machine! - with partial clones, and at some point the only way to scale up the server side is to not use Git repos, and break them up into object storage (this is what Azure DevOps does). So... it's no longer Git on the client, and it's no longer Git on the server. Why are we clinging to this thing?

This is what it looks like when a technology has reached it's EOL, and it's time to find something new.

Individual developers will 100% be using it... we'll all have the same free accounts on GitHub or GitLab or whatever hoster we use, and when we start up projects, they'll just be in Grace repos at those hosters. The vast majority of developers don't care how their version control works, they just want it to work. Grace is so much easier to understand than Git, and few people care about how much is local and how much is cloud, as long as it works and it's fast.

No one will force you to use Grace for your individual projects, but at some point, after using Grace, I don't think you'll want to go back. If you want to keep using Git yourself, it's not going anywhere.

I find it amusing how attached to "local repos" some devs have become when we have everything else we do live in the cloud, or synced to the cloud, and it's not a big deal. Source control isn't a different category of thing that must be local. It's just a no-longer-relevant habit from Git.

[1] https://github.com/ScottArbeit/Grace/blob/main/docs/Design%2...

A better question is: why does git only have one gesture for it, when devs clearly use it to mean different things already?

All of the squash vs. no squash debate, which may or may not influence the way you use `git commit`, is a workaround - that we've forgotten is a workaround - for the fact that Git has only one way to say it.

Another way to say that: one of Git's leaky abstractions - the "commit" - forces us to use workarounds to make sense of it and how it's used and where it should be tracked and shouldn't be tracked.

Grace just decomposes those separate use cases into their own gestures to make it easier for you to track your own work in your own branch. If you want to see all of the references in your branch, `grace refs`. If you only want to see the checkpoints and commits - i.e. you want to see the versions that you explicitly marked as interesting for one reason or another, you have `grace checkpoints` and `grace commits`.

Promotions are what Grace uses instead of merges to move code from a child branch to a parent branch. We sometimes call merges "commits" in Git, and, again, leaky abstraction and overloaded term.

> so I think most git users will just get the impression that grace imposes a particular workflow and forces the user to perform extra administrative tasks

A short intro to Grace - like 15 minutes - will change that impression, I hope. Most of Grace's workflow will be the same as Git, some of it will be different, and that's OK. New tools bring new ways of working, and that's a good thing, especially when looking at Git's UX.

I agree, complexity bad. So why do you like Git? :-)

Git is _incredibly_ complex to understand, as proven for almost 20 years by the vast majority of people who have been forced to use it. And by quite a bit of academic and industry research, for instance, [1].

I can teach you Grace in about 15 minutes. How many days and weeks does it take most devs to start to understand Git? And even when they do, for most, it's only the basics, and please don't let anything go wrong. I mean, there were people for over a decade who made their living running week-long workshops on learning Git. I don't see how you could run a half-day-long workshop teaching Grace, unless you go really slowly.

If you're one of the probably 20% or so who really feels like they understand Git and are in control of it, that's awesome. But you're projecting your experience more widely if you think that's the norm. It's not.

As for local, well, if you're working with a team on GitHub or GitLab or Azure DevOps or some other hoster, you're already doing centralized VCS, you're just using a decentralized VCS to do it. Most shops don't let you push to production from your dev box, right?

[1]: https://static.googleusercontent.com/media/research.google.c...

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.

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.

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

> Programming absolutely has an artistic side.... You don’t get that from a pure engineering approach. Mathematicians know what I mean here.

There's a reason I'm writing Grace in F#, after all.

One of the design intentions for Grace is to make version control more ambient, more something that just happens in the background, so you get the benefits of file-level undo and diffs and change tracking without having to do anything, until you're ready to run `grace commit` and `grace promote`.

I'm like you: for small personal projects I either don't bother with source control, or I update it rarely. I'm the first beneficiary of the ambient approach that Grace has; it's really nice to just have all of my previous versions automatically uploaded and tracked, and then deleted a few days later if they're not pointed to by some other reference like a commit or promotion.

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.

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.

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.

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.

Awesome question.

Obviously, the intention is to get there. It's still an alpha, and it's not ready to be trusted for real yet. (And that's OK.) There are a lot of features yet to be written.

With that said, it does do the basics well: save/checkpoint/commit/promote/tag, diff, status, rebase, list refs, ls for local version, ls for server version(s), etc. And it's fast. Still much more to do.

Funny story: At the beginning I was using both Git and Grace at the same time (a .git directory next to a .grace directory to drive them) on the source code. Then I worked on auto-rebase, and had a bug that deleted some of my source files . I was able to revert from Git, of course, but after that I decided to do my testing in other directories.

Hi! Which one are you working on? (I created Grace.)

I'd love to chat... I've spoken to the creators of several other VCS's, it's a nice group of people. Hit me up on Twitter or whatever, I'd love to hear what motivated you, and what you're solving for.

You're not alone. My experience is that about 20% of devs deeply understand Git and are very comfortable with it, and about 80% know the the basics and hope nothing goes wrong.

I'm somewhere in the middle myself. That's part of why I designed Grace to be much easier to understand. I can teach it to you in about 15 minutes, not the days and weeks it takes all of us to feel like we understand Git.

> Also this means I can't easily run it locally?

It's not meant to be a local version control system, unless you enjoy running local Kubernetes clusters (which I have to do, but don't enjoy).

It's meant to be the next big thing in version control - no reason not to go for it - which means that it would have to be picked up by the major source control hosters, and since I know what it takes for GitHub to run its infrastructure, I know that it makes much more sense to build something new on PaaS services, not on file servers. Not anymore.

> I already understand git, so does everyone on my team, and everyone that interviews...

Yeah, but do they? That's not my experience, and it's not the experience of most people I talk to about it. Most devs I've asked about it understand the basics of how to use Git, but they're still afraid of it if anything goes wrong. My guess is that the ratio is 20% deeply understand it, and 80% only know what they need to and hope nothing bad happens.

Maybe your team are all a bunch of reflog wizards... that's awesome. And uncommon.

And I almost always get laughs and head nods when I talk about the problems with Git's UX.

> Is large files the main problem this solves?

No, but it's a big problem for gaming companies, who are mostly stuck on Perforce. And Git can't handle them well without the bolted-on LFS. And with the rise in monorepos, more and more enterprises want to be able to store more and bigger files than ever before.

> And maybe requires an internet connection?

Yes, absolutely, it does. So does Git if you expect to push anything anywhere. And if you happen to be doing dev using Azure or GCP or AWS you need one too.

Building something that would become popular in the late 2020's, and assuming that users will have solid Internet connections (don't forget satellite) is what makes sense. If you're still in a situation where you need offline VCS then, Git will still be there.

> Maybe this is for pair programming?

You could use it for that, but pair programming is not a direct design intent.

Hi! I created Grace. AMA...

I never wrote any SNOBOL, but definitely remember it from Tron.

https://csh.rit.edu/~jerry/arcade/tron/index.html

Back in the early 90's, I used REXX a lot for string processing and shell-type tasks, it was a great language.

Go to Personalization / Taskbar. Turn off the widgets icon. Hide the Search bar. Turn off the Chat icon.

Voila! Just Windows. Instead of cursing at the sky, I just turn off what I don't want.

MacOS is an old, outdated clown car of an OS that looks like it hasn't been updated in 15 years. Let me know when the Year of Linux happens.

Meanwhile, Windows is the most efficient, easy-to-use OS for development and media tasks. WSL is amazing. Hyper-V is fast if I need it. And it all Just Works.

Astronomers aren't lying to us to sell smartphones based on the quality of advertised images.

This feature has existed since Windows NT. Nothing has changed about it. By default, Windows will raise the priority of foreground apps a tick. You can turn that off if you want.

Sitting on the Microsoft campus at the moment... not a kernel developer. <looks around> yeah, this is not hell. Not even a bit.

Microsoft is great. It's an amazing place to make impacts in many different areas of technology. Work teams used to be more siloed, but that's changed a lot in the last 6-7 years. We regularly work across teams at GitHub and Microsoft to get things done with great cooperation.

As for Teams vs. Slack vs. Discord, it's a personal taste thing. I'd rather have Teams over Slack + Zoom 1000x.

Take the Windows kernel job! Worst case, it's not a fit and you move on, like any other job. Best case, you stick around for a long time and have a great career working on tech that 1B+ people use.

When Robert Downey Jr. was trying to talk Gwyneth Paltrow into joining "Iron Man", he said to her something like, "do you want to work on art house films the rest of your life or do you want to be in something that people actually see?"

Windows is massive... it's the largest code base that I'm aware of. It has a ton of process and procedures and test cycles because... it's Windows. Of course you can't just freelance there. But you can "be in something that people actually see", and most SV startups will never even get 1,000 users, much less 1,000,000,000+, and more if you count the users on Azure services using Windows indirectly.

It's good to know that this year is the year of the Linux Desktop. Just like last year. And the year before that. And the year before...

When taught rooted in a mystical spiritual tradition, yoga and meditation are enormously important ingredients in quieting the influence of the ego.

When taught as productivity or wellness hacks, yeah, you'd get the result that this study did.

It's not about how good you look doing Downward Dog. It's about taking a break from the incessant mind-chatter, and getting a chance to experience the present moment, whether through movement or stillness.

Pick a new-to-you technology you're interested in, do File/New Project... on it, and just build something. Give yourself permission to be a beginner again. Build something that no one else will see, but that you'll regain your confidence with by proving to yourself that you're still capable of learning and growing. You'll see that something that took you 20 hours to do in week 1-2 will take you 20 minutes in week 8.

And remember: this is art, not science. We all make artistic decisions about how to do things in programming all day (we pretend it's science or engineering... it's not) and you will, too. Give yourself permission to do things how you want to, it's all just a learning opportunity.

I did this when I turned 40 after years of being an architect... it refreshed my love for coding.