Scott Arbeit is a Super-technical architect at GitHub. He joins the show to talk about his project, "Grace". It is a modern, cloud-native version control system, written in F#. They begin by sharing their own perspective on why they believe "Git" is unique and popular. Additionally, he explains his project, how it works, its features and how it improves user experience. 

Christian Wenz (00:01.314)

Hi and welcome to yet another episode of Adventures in.NET. I'm Christian Wenz, one of your hosts, together with my friend and colleague, Adam Furmanek.

 

Adam Furmanek (00:12.446)

Nice to meet you folks.

 

Christian Wenz (00:13.974)

And today we once again have a special guest, will be a great episode. We have Scott Arbeit here. Hi Scott. Where are you calling in from today?

 

Scott Arbeit (00:21.41)

Hello?

 

Scott Arbeit (00:25.901)

I'm calling in from just outside Seattle in Issaquah, Washington.

 

Christian Wenz (00:29.826)

Fantastic! So, happy to have you on board today. So what have you been working on?

 

Scott Arbeit (00:34.157)

Thanks for having me.

 

Christian Wenz (00:38.85)

Hahaha

 

Scott Arbeit (00:39.386)

Well, my day job is I work for GitHub. I'm a technical architect at GitHub, so I help customers do whatever they need to do to use our platform well and maybe fill in some glue in places where we can add to the product. I think we're really here to talk about my side project, which is a brand new source control system called Grace.

 

happy to go into quite a bit of detail about that.

 

Christian Wenz (01:05.922)

Fantastic.

 

Oh, absolutely. I always loved that. I mean, what was what was the first control system you all have been using? I think I did visual source save for a while. No, no, before that, I think I did BAK files via FTP or something. But but yeah, yeah. So quick, quick

 

Scott Arbeit (01:17.653)

Yeah, that was mine.

 

Scott Arbeit (01:24.155)

Yeah, okay.

 

Scott Arbeit (01:29.197)

Sure.

 

Scott Arbeit (01:34.602)

Mm-hmm.

 

Christian Wenz (01:37.354)

Wasn't there then this discussion whether Mercurial or Git kind of would be better? And supposedly it was Mercurial but Git won at the end maybe because of its famous inventor, I don't know. Or maybe it was just superior.

 

Scott Arbeit (01:45.057)

Mm-hmm.

 

Adam Furmanek (01:45.688)

TFS probably.

 

Scott Arbeit (01:55.949)

It's interesting. I mean, I think GitHub one of GitHub get I think get one for a couple reasons. First of all, I think the branching mechanism, the lightweight branching and for those of us who came from, I came from source safe and I spent a lot of years using TFS I was a TFS administrator. So if you've ever installed TFS and had to install SharePoint and had to install SQL Server and I like I've been there. So, um, I think, you know, when you look at what branching was in some of those older source control systems.

 

was this really heavyweight.

 

that was a kind of a stop the world event and Git came along and said, branches are just a reference. It's super easy, lightweight, go make as many as you want. I think that helped. And I think the ephemeral working directory, like the idea that you had a working directory, but like where your source code was kept was in another directory. In this case, the.git directory,.git objects made Git feel much lighter weight, even though it's more complex. So I think that helped it win. And also like give credit to GitHub. GitHub popular.

 

and put it on the web in a way that was unique. And ultimately how trends happen in our business is kind of interesting, but Git clearly has won. Git has 94% of the market or something like that. And yet new things will come.

 

Christian Wenz (03:19.43)

they always will.

 

Adam Furmanek (03:20.97)

Yeah, the other thing that Git had unique at the time, at least from my perspective, but I never used SourceSafe and other dinosaur technologies you folks mentioned, is that it could work offline. You could do anything without talking to the main server, and TFS and its locking mechanism, that was quite a hike, right?

 

Scott Arbeit (03:29.089)

Thank you very much.

 

Scott Arbeit (03:41.341)

Yep, that was painful. The offline aspects of Git were important in its development. I think when you look back at the, particularly, it was invented in 2005. So when you look back at the...

 

the world of computers in 2005, if you were in the quote unquote developed world, well you had a good internet connection and you had a good enough computer. But in lots of places in the world, you didn't have a steady internet connection or you had a very slow internet connection if you had one and you had smaller computers, smaller disks. So the constraints in which Git was written and again, by a kernel developer, right? So Linus is brilliant. Linus thinks in terms of how can I pack things

 

and ship the fewest amount of bytes over the, like as he should, like that's what kernel developers do. I love assembly language. My second language when I was 11 years old was 6502 assembly. Like it's cool to be down to the metal, but ultimately like those constraints from 2005 don't apply anymore. And as you look ahead, like, I mean, and I say that because Grace is a centralized version control system, Grace does require an online connection to do anything more than anything trivial.

 

I mean, you can still work if you happen to be offline, you can change your code there and we'll catch up when you reconnect, but you need to be connected. And I think, you know, even starting today in 2023 and looking ahead to satellite internet and just, you know, looking ahead to when something might take over from Git in 2026, 27, 28, like the internet connection thing won't be a problem anymore.

 

So, you know, you have to, as they say in hockey, skate to where the puck is going.

 

Adam Furmanek (05:30.794)

Yeah, there is always one thing which was pretty hard for me in the early days of me using Git. And I heard many people did the same. I mean, it's quite easy to break something in Git. I mean, when you start doing rebase, squashing stuff, branching and other things, some people even recommend you, yeah, before doing all that, just copy things on the site. And obviously...

 

Scott Arbeit (05:56.151)

Yeah.

 

Christian Wenz (05:56.27)

Yeah.

 

Adam Furmanek (05:56.882)

once you learn Git and especially once you learn Git reflog, you are good to go, right? Git reflog is actually the most powerful command in my opinion for Git. And I'm just wondering, and it's always surprising me that many people, many developers, they don't know this command at all and they still copy Git repositories on the side. So even though Git is super powerful and once you learn Git reflog, it's super easy, still some people struggle with using that.

 

Christian Wenz (06:01.794)

I'm gonna go.

 

Scott Arbeit (06:15.927)

Mm-hmm.

 

Adam Furmanek (06:26.582)

complain about documentation, about the comments and the naming conventions and all those comments. So generally getting these things even though Git is prevalent doesn't mean it's perfect in all these aspects.

 

Christian Wenz (06:31.054)

Mm-hmm.

 

Scott Arbeit (06:38.053)

Yeah, you know, Git certainly has a... And you know, actually, before I continue, let me make a couple of disclaimers. First of all, I should have started with this. Like, I do work for GitHub, and I am talking about a source control system.

 

However, this is a side project. I wanna be very clear. I am not announcing anything in terms of GitHub. I'm not, like this is not a GitHub project that I'm talking about. So I'm inspired to, I was inspired to work on it by my experience at GitHub. And I, you know, we can talk about that. But like, I just wanna be very clear. I'm not announcing anything on behalf of GitHub at all. So that's the first thing. And the second thing I wanna say is like, as we talk about source control and talk about Git and some of its challenges,

 

have the privilege of knowing some of the core maintainers of Git. My first role at GitHub was as the product manager for Git systems and that's the team that actually codes and runs the systems that support 250 million or I don't remember what our current public number is, but nine figures worth of repositories.

 

Welcome, Sean. And so like those developers, and particularly the ones that work on core Git, are some of the most impressive engineers I've ever known in my entire career. They're amazing developers. And if I say anything mean about Git, and I probably will, that is not a reflection on how much...

 

Christian Wenz (08:08.426)

That's why we're all here for, right?

 

Scott Arbeit (08:10.745)

That is not a reflection on how much I love and respect that entire team. They're amazing. With that said, you know, certainly Git has significant UX challenges. Git is really hard to learn. It is very confusing to learn. It requires you to shift the way you think.

 

to mold your mind into how it views the world. And like that is to some extent, the definition of bad user experience. Good UX is one that's a little easier to adopt and I've worked really hard in Grace to go for that, like easy to use, easy to understand and still powerful. Yeah.

 

Christian Wenz (08:46.174)

Also the vocabulary, I think, sorry for interrupting, but the vocabulary thing is also important, right? So push, commit, especially when coming from older systems, right? But what happens when, yeah, yeah.

 

Scott Arbeit (08:54.313)

Right. And, and also it is, I'm sorry. You know, it's, it's interesting. Like, like one question that comes up a lot is like, why is Git complicated? And some of it I think is, well, it was developed by a kernel developer.

 

I don't usually look to kernel developers for good UX. That's not how they view the world and that's okay. The second thing though is that it is distributed and ultimately Git's job is to synchronize a pile of bits across space and time. And that is a mathematically complicated thing to do.

 

And the command surface to make that happen is necessarily somewhat complex. It doesn't necessarily have to be the way Git does it. There are other projects that we'll talk about that are doing that still do distributed, but do it in a maybe easier, easier way. Um, but I think the fact that it's distributed adds a layer of complexity, and which is why I chose not to, I chose to do centralized because there's an entire layer of complexity, like pushes and polls, for instance, like there is no poll gesture in grace, there is no push gesture in grace, there's

 

not they're not required. So so I don't have like, it's not a pull request in for instance, in grace, it would be a promotion request. And we'll talk about that. But but yeah, I you know, it's a fascinating thing. It's also interesting, I think to watch people's emotional reaction when I talk about this. People are there some are really emotionally attached to get and I think, you know, it's a hard one skill.

 

And I completely understand that like, if you put in the work, like you like, Adam, you talked about reflog, you're right. Like my anecdotal, this is completely anecdotal, I don't know the actual numbers, is like 15, 20% of Git users really learn it and know it and feel comfortable in it and aren't afraid of it. And the truth is 80% are. Like, again, I'm making up that number, but I think that's probably close to true. You know, it's that old XKCD comic.

 

Scott Arbeit (10:59.421)

about like, here's Git, what is it and how do you use it? Well, just memorize these five commands. And if anything goes wrong, delete your repo. Um, and I think that's where most. Right. And I think that's where most people are with, with Git. Um, and, and at some point we need to stop blaming the users. For being there for like getting that far and no further, like at some point we have to look at the software and go, what is causing people to only go so far with it? Um.

 

Christian Wenz (11:07.374)

That's how I roll.

 

Adam Furmanek (11:07.783)

Exactly what I meant.

 

Adam Furmanek (11:29.29)

Yeah, especially that like when we think about Git source control, that's my opinion. It's not the main tool under our belt. I mean, we do use it, but we don't use it for the sake of using it, right? It's just the tool that helps us do the work. We are not like a Git developers, right? We are not the developers or whatever else and Git just helps us do the work. And if it, it makes it harder.

 

Scott Arbeit (11:29.591)

and we do the...

 

Adam Furmanek (11:52.898)

then it's actually like against the point. In my case, for instance, I'm super used to Git extensions, to mention, to recommend anything, right? But I just know this UI, I like it, I know how to, I see branches. This is something that I lack when I go to, I don't know, Visual Studio Code, IntelliJ IDEA or whatever else, right? I just don't see what's there in my repository. And I could learn commands, but that's not about that. I just...

 

Scott Arbeit (12:00.903)

Right, right.

 

Adam Furmanek (12:21.5)

get completely lost because I don't know what's there.

 

Scott Arbeit (12:25.677)

I completely agree. And get extensions is wonderful. That's a UI that I used to use a lot. Yeah.

 

Christian Wenz (12:32.938)

I mean, I understand the sometimes religious attachment to whatever you are using, right? But I mean, if you know something really inside out and are a bright thinker, at least that's kind of my lackless test, right? I always ask, name three things that are absolute crap in X. And if you know it well enough, you can name those three. And if you can't,

 

Scott Arbeit (13:01.003)

Mm-hmm.

 

Christian Wenz (13:02.862)

then chances are either you don't know the technology well enough to know not only the happy path, right, or you are a lobbyist in a way, right, or you're promoting something. So that's why I always, even with the things that are really dear to my heart technology-wise, as much as something technology-wise can be dear to your heart, even those things I constantly challenge because only then I know what could be better or if there's even an alternative, right. So I'm...

 

Scott Arbeit (13:12.321)

Okay.

 

Christian Wenz (13:31.398)

super eager to hear what your learnings with from Gitso to speak were and what grade UX or DX you came up with. So I'm really intrigued.

 

Scott Arbeit (13:35.595)

Yeah.

 

Scott Arbeit (13:41.429)

Thank you.

 

Scott Arbeit (13:45.893)

I, it's, you know, it is interesting. I think when people do get attached to their, to their technologies and you know, we're going to, Grace has written in F sharp. So, you know, that was for me doing a deep dive on functional and, and that is another area where people are super attached to object oriented and.

 

Christian Wenz (13:54.14)

Mm-hmm.

 

Scott Arbeit (14:04.885)

and the practices that are included in object oriented, like dependency injection and mocking and things that you don't actually need in the functional world. And people, again, have emotional reactions to it. It's kind of interesting. What I...

 

As far as, you know, grace itself, the way I've tried to make it simple is, again, first of all, it's centralized. So there's no pushing and pulling. There's no confusion about what's local or not. If you're familiar with git, sparse checkout, that's what is really happening locally. Like you have some of the repo, you have the most recent bits of the repo and the branches that you're interested in locally. But all the history is really up on the server. And

 

Of course it's open source. I see you just put the chat in the link, link in the chat I mean. Yeah there's a, it is open source please go check it out. github.com Scott Arbite slash Grace. Star the repo, watch the repo. I want all the stars, thank you. But ultimately like what I wanted to do is get the simplest possible thing that worked and my inspiration, my original inspiration the first night I started having even

 

thoughts about doing this was thinking about the OneDrive sync client and whether you're familiar with OneDrive or Dropbox or whatever system you're familiar with, the OneDrive sync client about three or four years ago got really good like they rewrote it from scratch and it just works like it's the slash ijw flag it just works.

 

And it's so simple and just, and I started to think, wow, what if I, what if there was a source control system where whenever something got saved to disk, it just automatically got uploaded to the server. What, what functionality could we build?

 

Scott Arbeit (15:56.337)

if we had that kind of an automatic, just like ambient flow of, of source control. And that's really where it started. And that's a big part of, of grace. Grace has a command called grace watch that watches your working directory. And every time you save a file on disk, it uploads not just that version of the file, but recomputes the Shaw values for the directories that go all the way to the route. And so you have, so every time you save on disk, there's a fully, if you want to think

 

repository all the way to the root that gets uploaded to the server. And that is what I call a save. And then you can you can.

 

Christian Wenz (16:35.246)

So it's kind of like a time machine, a macOS time machine on steroids, right?

 

Scott Arbeit (16:38.924)

Yes.

 

That's exactly, in fact, that was the time machine was another inspiration for me. Um, when I thought about a functionality that I could offer to users, once, once we had that ambient sort of upload all the time, one of the things I really wanted to offer and will offer with grace, I have not written it yet, but this idea of a time machine like UX, where you can just very quickly flip back and go, where was I like one of the things that I think, one of the questions that hasn't really

 

Scott Arbeit (17:12.029)

what else can we get from source control? Like we've added lots of functionality to our IDEs and they're beautiful. I love Visual Studio, I use VS Code.

 

And like we keep adding functionality at that level, but we haven't asked more of our source control systems in a long time. And I think one of the things you can get with that time machine like view is there's that famous line, especially for, you know, as programmers, when we get interrupted, it takes a while to reload state in our minds. And there's the famous number of people say it's 18 minutes. I don't know, it depends on the person and the interruption, right? But...

 

But there's this idea I had where like, if you could provide that time machine like view of, here's what I was just working on. You could flip back and go, what were my last 20 saves? And go, oh yeah, I remember I did that, I did that. I tried that, that didn't work. I backed it out. I did that, I did that.

 

and you could get maybe reload state in two minutes rather than 18 minutes and just kind of get back in the flow faster after every interruption. That's a feature that I really wanted to have in Grace. But having that automatic save thing is very useful. It enables some functionality. It's also like it makes people shift uncomfortably in their seat, which I understand because you can easily get into, am I tracking whether somebody's working?

 

right?

 

Christian Wenz (18:33.002)

I was thinking something else. I think there are two types of developers. Well, there are certainly more, but there are two types of developers. Those who edit five files at once, and once they are done, they do save all. And then there are those developers that save after every line. When I was younger, I wasn't saving. I was hitting Control-S like five times.

 

Scott Arbeit (18:45.645)

Sable.

 

Christian Wenz (18:56.45)

just to make sure that the thing is really written to disk. Now, I mean, since the file then only changes on the first attempt, right? Only on the first attempt, Grace would then upload, right? Okay.

 

Scott Arbeit (18:56.565)

Yeah.

 

Scott Arbeit (19:08.081)

Oh yeah, I compute the shala and check. Did I already have this one? Cool, I ignore it then. Totally, totally. I had to think about that for a short.

 

Christian Wenz (19:14.059)

Okay.

 

So you only take the only quote unquote, of course, you only take the contents of the files, not the timestamps, right?

 

Scott Arbeit (19:24.341)

I, well, I do capture them. How that, that's another interesting question that I think as we go further into Grace's development, when you, for instance, when you...

 

You know, if like you do your thing, you upload to main, right? Like you promote to main, right? You, in other words, in other words, merge, right? It's not, it's not technically a merge, but you promote to main. And then some other user now has to, you know, rebase on, on that new.

 

thing, here's a question, when we download that new version of the file to their machine, do we put the current timestamp or do we put the timestamp of when that file was uploaded to Grace? Like, I don't have an answer for that. I think that, you know, I could imagine that being a setting on a repo level. But it's an interesting question to say what's valuable for different people in that. It's funny when you dive into the corners and the specific features, like how much you see how people think differently and use it differently.

 

But yeah, like so having all those saves, just to talk about the potential downside, is this idea of like, well, gee, this developer hasn't done a save in two hours. Like what does that mean? And what it means is nothing. Like what it means is absolutely nothing. And I understand that there will be temptation from certain...

 

less informed managers, let's just say that, to use data, the metadata that's generated by using a system that does automatic uploads for ill.

 

Scott Arbeit (21:02.933)

Right, that temptation will be there and to some extent, the only defense I can make is just repeat over and over and over again, that's stupid, don't do that. And I certainly will, if Grace does catch on, that's a thing I'll be saying every time I talk about it, is like that is not what that feature is for. That feature is for developers, that feature is to make your life as a developer better. That's really what I'm interested in, is writing features that make, I'm a developer. I've been, I first started writing code

 

Christian Wenz (21:03.429)

Yep.

 

Scott Arbeit (21:33.247)

Like I love writing code. I still love writing a writing code. That was 42 years ago Next next month of 42 years as a programmer next month and like I still love writing code I still get that like little fist pump when like it works so like that, you know, I'm here for the love of the developers and all the features I writer for that so So yeah, but having all those saves with that said like with that

 

potential downside address. Like there's so much you can do with having automatic saves that, you know, aside from like, it's just ambient and it just works and it's just in the background. And every time you save, you know that your source control system is up to date, but you also then increase the speed of other commands. So there are commands and I'll get into why, they're checkpoint, commit and promote. And the idea for those is in Git,

 

Commit is kind of overloaded, right? Commit means I'm partially done with my work, right? That's like a local commit, right? And then there's the, okay, I'm committing because I'm ready to do a merge.

 

I'm ready to file the PR or push the, you know, whatever. And commit is also sort of a merge sort of kind of, and like in Grace, I've really broken those things out. So there's this idea of a checkpoint, and a checkpoint again is a developer feature. It's for you to mark this version is when I finished part one of this work or part two of this work, or I did something interesting, whatever it is, it's for you to make to mark.

 

that version in whatever way you want. But, and it gets rid of that whole, do I squash or not squash debate? That's what Git gets into. When you have these intermediate commits, that's why we get into this, do we squash or not squash? Like there's no, we don't have that in Grays, we don't need it. You just commit, and at some point, like there might be a PR where you get pushed back, and you go, oh, I need to edit this, I need to fix this, whatever. You do another commit. When you do that checkpoint or commit, if you were running Grayswatch, and the files are already updated,

 

Scott Arbeit (23:35.887)

Well, that creating that commit.

 

or checkpoint or whatever is creating a database record. It happens in under a second. It's super, super fast, assuming that you're within, you know, a couple hundred milliseconds of the data center, right? So you get a lot of performance benefits by running GraceWatch and having that automatic ambient upload happening. And then when you do a promotion to main, and I'm calling it, there's promotion instead of merge, because technically it's not a merge. Technically it's, here's that entire version of the repo

 

created all the way up to the root that I pointed a commit at and said, this is the one that I think is good enough to be promoted. And then a bunch of people, you approve it and you go, okay, promotion. And all I'm doing when I create a promotion is on main, I'm creating a reference to points to the same exact version of the files that's already there. It's again, I'm just creating a single database record effectively. So it's all those commands become super, super fast. I do have to, um, anyone who writes a source control system today has to think about the speed of Git. I mean, I give enormous.

 

Christian Wenz (24:23.182)

Mm-hmm.

 

Scott Arbeit (24:38.347)

credit. Again, like I know some of these engineers, they're incredible and get locally is incredibly fast. And so when you're doing an online system, you have to think about what can I

 

Be faster at and what can't I like I've like there are some things I can never be faster than get at because it's local But there are lots of things that I can be even faster at because I can do some of this work in the background ambient, you know in an ambient way So that when it's time to do the thing you're asking for explicitly it just happens really quick and that's certainly something I've targeted For you know speed is part of UX Right good UX requires good performance big believer in that

 

Christian Wenz (25:19.97)

So kind of the mode in which I would be developing with Graysys, you know, I do my coding. Let's just start with soul developer, right? So I do my coding, save this there and there. And then after an hour or so, I say, okay, now everything is working. And then I say, okay, I would like to have like a marker, and this is called checkpoint, right? And then later, if I mess things up half an hour later, I...

 

Scott Arbeit (25:27.041)

Yep.

 

Christian Wenz (25:46.978)

don't have to remember, okay, it was like 11 a.m. when the thing worked last time, but no, it was when I set that marker, set that checkpoint, and then just could revert or go back or however you call it in the system to that time in my developer mode, so to speak, in my developer flow, right? Okay, I like that.

 

Scott Arbeit (25:55.309)

Mm-hmm.

 

Scott Arbeit (25:59.638)

Yep.

 

Scott Arbeit (26:04.841)

Yes, yes, totally. And yeah, thank you. There's a, you know, there's a, there was a very interesting research paper from Google about 10 years ago. It was called A Case for Computational Thinking. If anyone...

 

wants to go look it up, but it was an exploration of version control and how users felt about it. And really what that paper exposed is how scared a lot of people were about Git and other version control systems. But one of the phrases that the authors of that paper came up with was the idea that version control was meant to be something that allowed for development without fear. In other words, like if I kept, if I was consistent about doing Git commit.

 

for instance, then I could always revert very quickly. And so like I could go explore and go, oh, that was a dead end, let me revert. And again, for various reasons, a lot having to do with Git's UX and people's fear of it, people are still afraid of Git, people are still afraid to do development. So if your goal for source control is to do development to enable development without fear.

 

Like I have to say, get failed. And so like I've made it, I've tried to make it as explicit and obvious as I possibly can to enable development without fear. And I think, I don't know how you get there. And like, I'll just talk about my own personal flow. I hit control S a lot and I don't commit often.

 

So like I'll be, I'm the guy who has been working on like, and this is Grace, like, of course, like Grace's source control is Git right now because Grace isn't ready to self-host yet. When, you know, as soon as it is, I certainly will. But I'm that guy who will work on something for two or three nights and then be like, oh, I didn't commit.

 

Scott Arbeit (27:57.845)

You know, and then like, oh, now I have like 17 files that I've changed and it's a little confusing about what exactly I did. And if we can imagine that, if we can replay that in a grace scenario, every time I hit save, I would have those, I would have those stored on the server and be able to use that time machine like view to go back. And so now I've created that development without fear. If I go down a wrong path, I can see, oh, that didn't work.

 

I can do better. So.

 

I look forward, I personally like, I mean, to some extent, let's face it, when you build software, you build it for yourself first, right? And so I'm really looking forward to having that sort of automatic save thing. And for what it's worth, just to mention a couple of other source control products that are going on, you know, I'm not the only one who has looked at the state of source control and thought, wow, maybe it's time for something new. And I think when you look at, when you just do trend analysis of anything in our business,

 

In on the developer side of it, nothing has ever gotten to 90 something percent of the market and then stayed there forever Like nothing zero things that I'm aware of have done that You know even like and of course as I said, I go back I go back a few years You know even the concept of relational databases which was dominant when you said the word database in the 90s and 2000s What you meant was? relational database that has fallen away

 

Windows was 95% of the desktop market and 95% of the server market. It's clearly not anymore. So all these things kind of have a trend cycle. And when you see something that is at the top of that trend cycle, like there's nowhere else for get to go, it's at 94%.

 

Scott Arbeit (29:49.553)

that's your indication in our business that something new is probably gonna be created soon that's gonna start taking that 1%, 2% and start to grow. And so like this is the time that, this is the opportunity, I think this window of time in 23, 24, maybe 25 where you can build a new source control system that might be happening. Google is building one called JJ.

 

which is a lovely system. I'm lucky to know that team that's building it. They're doing great work. JJ is a kind of a front end. It can be a front end for Git. It can be a front end for something that they might build themselves. And it's...

 

They share a lot of the views I do in terms of the problems of Git, and so they address them in a different way, but they do beautiful work. Martin, on GitHub, it's martinbonzijj, if you wanna go look at that. There's another project called Pyhule, P-I-J-U-L, which is named after a bird, Spanish word for bird, and it's actually a mathematically-based, patch-based distributed version control system.

 

piece of work, really recommend it. Plastic SCM is another one that Unity purchased a couple years ago. Pablo and his team have built something amazing. I actually get, like whenever I look at plastic, which isn't very often, because I get discouraged looking at it, like it's so, the UI is really, really nice, I have to admit. So I look at it and I get that feeling of like, oh, I'm so far behind. But that's really so, so like I'm certainly not the only one who's looked at this and went like, oh, maybe it's time.

 

I just want to throw my hat in the ring and do something that's really different from all the other ones so

 

Shawn Clabough (31:38.979)

Seems like you've been developing for just about as long as I have. But I started out with source code control was like visual source safe, you know, may it rest in peace. And then moved on to, you know, like source gear vault and team foundation server and things like that. And those were all centralized. And you have to deal with the, you know, checkout, check-in, you know, locking of things. Does Grace do something similar to that? Do you have to?

 

Scott Arbeit (31:47.345)

Yeah.

 

Scott Arbeit (32:02.039)

Right.

 

Shawn Clabough (32:08.044)

Check out and check in.

 

Scott Arbeit (32:09.437)

No, so that's a very interesting question. So no, first short answer is no, absolutely not, because I lived the pain of that. So no. On the other hand, one interesting feature that.

 

One of the other main source control systems is out there is Perforce. And Perforce has something that Git doesn't have, which is it's got a very nice ability to handle large files. And that's really why game developers, for instance, like any system that requires large binary files.

 

Perforce is still the sort of system of choice for those. And I had the opportunity to talk to one of the people who does source control over in the Xbox team. And they made it very clear that there is no way they could do source control without locking. Because unlike text files, like text files, if you edit lines 30 to 40 and I edit line 70 to 80, it doesn't really matter. But if you don't lock, let's say that I'm working on,

 

in Forza and I'm adding a few trees to turn three. Well, that's a binary file and there's no such thing as merging my changes with someone else's. I need to lock that file and be the only one editing it. So if I'm going to go after Perforce and I will, because, you know, Grace, by the way, we haven't talked about the technologies it's built on, but it's built on object storage, not on.

 

like local repo tightly packed stuff. It's built on something like, if you can imagine, imagine Azure Blob storage or Amazon S3 or whatever. So, you have unlimited file storage and you can handle unlimited file sizes with Grace. I've tested it up to 10 gig files so far. Not that I think 10 gig file should be in source control, but it does work. So, those users are gonna need locking anyways. So, it's a feature that I need to build in the future. I don't think it'll be in a 1.0, but I need to enable locking.

 

Scott Arbeit (34:11.407)

But by default, absolutely not, I agree. I think anyone who lived through that time has done the thing where it's Friday afternoon, the person locked the file you need, they're gone for the weekend, this is in the before days. And now what? And of course you then get the questions of like, but what if I'm on an airplane? And I kind of go.

 

I'm not writing a source control system for the 0.00001%. I don't care, right?

 

Shawn Clabough (34:46.027)

Yeah, and without locking or without the checkout and check in, then you kind of run into the situation where it's last person to say wins.

 

Scott Arbeit (34:54.229)

Well, I'm the last person in your branch. I mean, you know, again, you're doing your branch. So you're always in a branch, just like Git. So yeah, you can edit your files to your heart's content. It's only when you attempt, when you do a commit and then request permission to do a promotion to main, that's when that version would be promoted. Or again, in Git, you're merged. What's that?

 

Christian Wenz (35:16.258)

So can two people work in the same branch then? I can work two people on the same branch then at the same time, like a feature branch or something.

 

Scott Arbeit (35:23.197)

It's an interesting question. It's, it's theoretically possible. I haven't ever, um, really, I haven't deeply tested that. I, I messed with that one day to just see how it kind of felt. Um, it's, it's possible. I don't know that that's going to be a mainstream use case. And I think things like live share, Visual Studio live share are, are maybe a better use for that, um, pair programming scenario, but with that said, um,

 

Christian Wenz (35:35.031)

Yeah.

 

Christian Wenz (35:43.407)

Mm-hmm.

 

Scott Arbeit (35:52.741)

I could, you know, like there's nothing about Grace right now that prevents multiple people from having that, you know, from like my current branch is the same as someone else's current branch and whenever something gets updated, it gets pushed back down to the other user. One other thing, you know, I haven't, there's lots of stuff I haven't mentioned yet about Grace, but Grace, when you're running Grace watch, I use SignalR to have a live connection to the server. So there's that sort of two-way communication going on where when some, when an event happens in the repo.

 

all of these things is just, Grace is event driven in a very pure way. So all of these things are just events that can be used as triggers for behaviors. So you can, you know, like one of the things that Grace does that I think is very interesting and unique is auto rebasing. So when here's, you know, the four of us are working in a repo and one of us does a promotion to main and main gets updated, like within seconds.

 

all the other three will get their branches re-based on that new promotion in Maine.

 

provided there are no file conflicts. And what that actually does, what that does is, first of all, it reduces the number of merge conflicts or promotion conflicts in Grace terminology. And it also like pushes them forward in time. And to me, as a GitHub user, my goal when I create a PR, I'm somebody who creates a PR at the end. I know there are certainly people who, as soon as they start working on a task, create a PR that they'll eventually finish.

 

Christian Wenz (37:28.046)

Mm-hmm.

 

Scott Arbeit (37:29.539)

valid way to do it. I'm somebody who like does the work and then creates the PR. And so when I create that PR, my goal is to have the shortest amount of time between when I create that PR and when it gets merged. Like that's really what I'm trying to do. I want that button to turn green as quickly as possible. I want the approvals to happen. I want you know all that reviews to happen and get it done before I want that done before anything else happens that would cause a merge conflict.

 

Christian Wenz (37:33.003)

Yeah, yeah, I understand.

 

Christian Wenz (37:51.551)

Mm.

 

Scott Arbeit (37:55.893)

That's really the number one fear. And I think merge conflicts are one of those things that.

 

causes anxiety and fear. So another goal of Grace has been from the start to minimize merge conflicts. And auto rebasing is one of the main ways that I do that. And what that also means is that as soon as it does auto rebase, if there is a conflict detected, I can tell you right away. And I can go, hey, you wanna just take a look at this real quick. And while you're in flow, while you're working in the code, while you've just edited that file that just also got edited by someone else, well, you know what you just did.

 

look at it resolve the conflict immediately with a good UI and now you don't have to think about you have to worry about it at the end so

 

Christian Wenz (38:39.13)

So how is that mage emerge conflict UI? I mean, if you resolve the conflict by either using the other people's version or your own version, then you can, again, point to that specific hash or timestamp, right? So you are directly in your model. But what happens if you have to take half of A and half of B?

 

Scott Arbeit (39:04.237)

Well, I mean, whatever it is that you take out of that merge conflict, and to be clear, I have not written this UI yet. I will be creating a GUI using Avalonia for sure. But I'm a big believer in native UI. I hate Electron and I could shit on Electron forever. I don't know if I'm allowed to curse on this podcast, but I just did.

 

Christian Wenz (39:07.906)

Mm-hmm.

 

Christian Wenz (39:13.885)

Oh, nice.

 

Christian Wenz (39:27.299)

Fair enough, so you don't like slacks or teams or something? I mean once they are loaded?

 

Scott Arbeit (39:31.401)

Uh, not a fan, not a fan of anything. I just like, I just, uh, you know, like we have the way I always say it is like we have this first rate hardware.

 

You know, I'm talking, I'm speaking to you on a computer with a 24 core CPU and a 12 gig video card and you're telling me the best UI you can give me for that is something in a browser. Like, I'm sorry, I don't accept it. Like, I don't think that, I think we're doing a disservice to ourselves doing that. So I will create a native GUI. Anyway, you know, as far as the merge conflict thing, at the end of that, whatever it is that you resolve.

 

All that is, all of that resolution is, is a new version of that file. That's all it is. It's a new version of that file that becomes a new save that you can then checkpoint or commit or whatever. So like, that's all it is. I don't have linkages in Grace back to like, oh, but this one was based on this version and this version the way kind of Git does.

 

It's not necessary. It's necessary in a distributed system to understand kind of provenance, but it's not required in a centralized system at all. So I don't have it. If it becomes a problem, one could imagine adding some tag or something, but it becomes metadata, not primary data, if you will.

 

Adam Furmanek (40:57.706)

So I would question this a little bit to be honest, like many times I had the big merges, which I had to start from scratch a couple of times just because I messed it up. I use KD free and I think I kinda understand this tool. I know what to do. And still when there is a bigger merge, especially when someone renames variables or whatever, things get messy, right? So in...

 

Scott Arbeit (41:01.346)

Yeah.

 

Adam Furmanek (41:23.294)

Your case, if I'm getting that right, what you're saying is that when someone submitted something or promoted something that would cause a merge conflict or conflict on my end, I am resolving that I basically create a new save and I don't have this like freeway branching or freeway history that KD3 shows me, right? But what if I need to start from scratch? How would that look like?

 

Scott Arbeit (41:34.604)

Yeah.

 

Scott Arbeit (41:49.741)

Um, I don't have that yet. Uh, and I don't, I'm not saying in no way am I saying you're wrong, you know, and like this, so far this has been a solo project. And so I look forward to, um, getting this kind of feedback and, and hopefully building a community around it and building features that people really need, um, my experience as a developer is that I haven't needed that. Um, and again, like it's not, it's not that I haven't.

 

once or twice in my career run into such a bad merge conflict that I just had to be like, I don't know what's happening here. I gotta think it through from first principles.

 

Again, when that happens, it's just another version of the file that I'm saving. And you can certainly, you can get away with that and you can create tags on any version you want, not just checkpoints, but I have a tag, in other words, a label. So if that's helpful in terms of metadata, and if we find out that this is a requirement that programmers have, that it happens often enough that it causes pain, I'm completely open to adding the right features

 

people comprehend how source got to the state it's in. One interesting thing about doing auto rebasing like that is it will expose when there's a really big file in a system that everyone edits all the time.

 

So like, and that's actually a code smell. I saw this presentation on YouTube once and I can't find it anymore because the title was like not related to the topic. Unfortunately, I can't remember it. But the point of the presentation was this guy did research and looked at a large code base and looked at the bugs that were reported against the code and looked at the files that were involved in the PRs where those bugs appeared. And what he found was that

 

Scott Arbeit (43:49.513)

the files where most bugs appeared were the ones that everyone edited all the time. In other words, if you think about a crime scene, it's like where the pathways where everyone walked through the center of the kind of crime scene as opposed to like the other pathways around it. And so doing auto rebates will expose those files as painful pretty quickly. And the truth is...

 

their code smells like we shouldn't have files that everyone edits all the time. That's a bit, that means we need to refactor those files. So, so as, uh, people maybe migrate to grace, um, one of the things that will probably end up happening is there'll be those two or three or four files in your repo that are just really big that you might want to just like factor things out so that they don't appear in every update. And then a lot of those problems about merging that you're talking about go away.

 

Adam Furmanek (44:41.258)

I think I saw the presentation you're talking about or something very similar it rings me about that could be Greg Young talking about matrix cyclomatic complexity but

 

Scott Arbeit (44:51.881)

It was not Greg Young, I love Greg Young and it wasn't him. But I know, I know, it's driving me nuts.

 

Adam Furmanek (44:56.286)

Okay, but anyway, the outcome was exactly as you were saying, when we can check the Git history or whatever, source control history, and see which files change the highest number of times, and this is probably the problem with our architecture and whatnot. So yeah, and the other thing that comes to my mind, apparently...

 

Maybe we are just dealing with different code bases. That's something that came to my mind about those freeway marriages is something I see that pretty often. And I'm a little bit surprised you say you don't see that or you saw that like once or twice, yes? Apparently we are doing things different, but the same thing. I remember my first days in Amazon when I joined the company. Like...

 

Scott Arbeit (45:27.39)

Oh.

 

Adam Furmanek (45:40.738)

When I was coming from the industry and I was doing pull requests, to me it was always like this. There is like main branch, I'm creating the feature branch, push it to the repository and I do pull requests from my feature branch to main branch, right? This was normal to me. And it was surprising to me when I learned in Amazon that it's not the way it works. You take the main branch, modify it locally and you do the pull request from main branch to the main branch.

 

Christian Wenz (45:50.265)

Thank you.

 

Adam Furmanek (46:10.87)

And there is a tool that basically copies your main and creates something behind the scenes. So it took me a little bit to understand when I was trying to do feature branches and doing them to request the old way, what is going on in here?

 

Scott Arbeit (46:25.609)

Right. And Google does it differently too. Certainly large teams can have their own way to do it. I was obviously modeling the way Git does it, because that's how 99% of us understand how it works with feature branches. The good news about creating something from scratch is that it's a green field, and I can do whatever I want right now.

 

Christian Wenz (46:52.484)

Yeah, you can be opinionated, right? And I mean, rightfully so, right? Absolutely. Yeah, absolutely, absolutely. Oh, I find this super, super fascinating.

 

Scott Arbeit (46:55.254)

I give you opinionated, I give you open. Yeah.

 

Scott Arbeit (47:02.209)

Thank you. And you know, like the good news is you can learn grace in about 10 minutes. Like the truth is, I could, if I really, I mean, you already understand an awful lot about grace.

 

There's not a ton more to it than I've already said out loud. The only other thing, the main thing I would add is that this idea of like saves that happen automatically, they're ephemeral. Like I only keep them for, we'll set it by the repo, but imagine seven days. Like if that version of the repo that you did save, and then you did a checkpoint or you did a commit, well that one is going to hang out for a while.

 

you know, commit is gonna hold hangout forever. But all those saves, if nothing else is pointing to them, after seven days, they just get deleted. So it's, you know, it's not, you know, we're not just building and building and building. So you could imagine that, you know, the size of a regular repo plus seven days worth of additional single files, which is really not a ton of space. And last time I checked Azure Blob Storage, I had a lot of...

 

So, you know, I'm not concerned about storage in that way. So we're just cheap. So like that's really it. If you understand the concept of like saves, checkpoints commits promotions and you understand that saves are ephemeral, like you kind of know grace.

 

Christian Wenz (48:07.97)

Storage is cheap, right?

 

Scott Arbeit (48:21.921)

In a significant way, there's obviously more to it, but that's how simple I'm trying to make it. And I always say to people, like imagine, you know, compare that to your experience learning Git. It took a little bit longer, I'm gonna bet. And the joke I always like to use is being, you know, of course Grace has written in F sharp, so I've gotten into functional programming. And I like to say to people, would you rather explain Git, or would you rather explain what a monad is?

 

to someone. And I'd rather explain what a monad is. Monads are not hard to describe. Git is quite a bit more challenging, I think. So and that's really the level. I'm trying to avoid all that. I'm trying to make it really, really simple to understand. I know we've been running for a bit. I would love to talk for just a couple of minutes about functional programming if that's a. Yeah, please.

 

Shawn Clabough (49:12.327)

And one more question here is that, you know, when that promotion, like somebody promotes to Maine, does that everybody else get that automatically in behind the scenes or does everybody get prompted, say, hey, there's been a promotion to Maine, would you like to accept those changes to your local copiers?

 

Scott Arbeit (49:18.135)

Yeah.

 

Scott Arbeit (49:31.401)

Right.

 

To be determined, right now, the way Grayswatch is written, it would be notified and just do it automatically. That's just kind of how far I've gotten with writing that code. I imagine when we get into the level of integrating it with IDEs, for instance, we're all pretty spoiled. I mean, all the IDEs have done a ton of work with Git and making them flow well in the IDEs. If you can, again, skate to where the puck is going.

 

you know the next integration of it. I can certainly imagine a switch where you go don't auto rebase like let me know and let me decide that. I know I kind of expect to write that feature. I just haven't yet.

 

Christian Wenz (50:17.856)

Excellent.

 

Scott Arbeit (50:18.293)

But I do think that's a user call.

 

And also to be clear, like Grace can be used without GraceWatch. Like you can use Grace without doing the auto saves and all that stuff. But what it means is that, let's say I'm not using GraceWatch and I'm just writing code, I'm saving files, doing all the things, and then I'm ready to do a commit. Well, at that point now I have to kind of inspect your entire working directory to see what's changed and I have to check it against what the server has. Like I have to do some stuff that just means it takes an extra second or two. And if it's a really large repo,

 

seconds. So grace watch is that performance benefit in that situation but you don't it's not strictly neat I obviously understand that there are lots of situations where that won't be possible to run something like that even though it's super lightweight and easy and it doesn't if it's not doing anything it's really I've watched it in process map monitor it doesn't do anything you know it's really lightweight but yeah you know we have to plan for those sorts of scenarios.

 

Christian Wenz (51:19.79)

All right, excellent. We are almost out of time, unfortunately. However, please, Scott, do come back because I would be so interested in learning about why you chose F-Sharp and whether that really facilitated all of the implementation. I think that would be another fascinating topic. So I would be super happy to have you back, but you cannot leave without providing us with your pick if you would like to start.

 

Scott Arbeit (51:27.263)

or happy to.

 

Scott Arbeit (51:36.734)

I'd be happy to. It's a.

 

Scott Arbeit (51:42.003)

I cannot live.

 

Scott Arbeit (51:47.445)

Wow. Um, you see like you saw. What? Why don't you start while I look through my YouTube history really quick? Because I know I've been full stop.

 

Christian Wenz (51:50.034)

or should we start and which would give you two extra minutes.

 

Christian Wenz (51:56.862)

Okay, perfectly fine, perfectly fine. So before Sean was here, I was considering doing something from streaming, but now I can use the tool I wanted to mention. So this time it's software again because I'm done binging a hijack on Apple TV Plus.

 

And I would like to quickly mention JSCPD. That's a copy paste detector. So I have this quite often when I'm analyzing code bases. So when I'm doing due diligence of some company's tech stack, for instance, that sometimes depending on how software is written, especially big complex software, new people getting on board it, they kind of look at other parts of the application.

 

And then use the only software pattern we can all agree on upon write a copy and paste. And so JCPT is a super fast, I think it's O of N, super fast, on average, super fast command line tool, but it's also an API. You can use it from Node.js, et cetera, that detects, copy and paste. They're using algorithm that is kind of hashing. So it's looking for hashes, but it's like a rolling hash. So it kind of looks everywhere for that hash.

 

And it's super interesting when analyzing code bases to just see, OK, what's the amount of copy and paste? And if it's a lot, then maybe you can kind of find a better way by using whatever templates or create a component or stuff like that. Really useful. And so if that's something you could use, please feel free to check it out. Over to you, Adam.

 

Adam Furmanek (53:44.738)

Thank you. So my pick for this week is software application that is called UnitedSets. And generally if you ever use browsers you know you have tabs. But how cool would that be to be able to take two completely independent applications and make them tabs in one window?

 

This is something you could do for many years, for instance, Konemu, console emulator was capable of doing that. And now there is a separate app, United Sets, that you can just download and try doing exactly that. Still beta, not working perfectly. It likes, for instance, shortcuts. I mean, Control Tab is cool. We would like to have that done in some intuitive way.

 

Also, if you try capturing like browser window and then you hit Control N to create new window for this browser, it jumps out of this United set. So definitely some still room for improvement, but generally really, really nice idea, especially that if you are like a big fan of multi containers in Firefox, but you need to use Chrome.

 

Christian Wenz (54:55.99)

Mm-hmm.

 

Adam Furmanek (54:57.614)

So you can use Chrome with multiple profiles, but hey, they come with different windows. Now you can make them tabs inside one window. So pretty good use case, at least that was mine. But as I'm saying, some more ends like I's to dot, T's to cross, but hopefully may be useful. So that's my pick for this week. Over to you, Sean.

 

Scott Arbeit (55:05.184)

Hmm.

 

Christian Wenz (55:10.146)

Pretty cool.

 

Scott Arbeit (55:22.645)

Nice.

 

Christian Wenz (55:22.836)

awesome.

 

Shawn Clabough (55:25.239)

All right. So earlier today I was looking for something that can update my little avatar images that I have in like Microsoft Teams or other different places things like that. So I wanted something that could take an image of me and basically convert it into a cartoonish or you know, it's comic style look and I came upon a site called FOTOR F-O-T-O-R

 

and I thought it really did a good job. I haven't found the one that I actually want to use, but it gives you a couple different credits to get started with and then you have to pay after that, but it seemed to be pretty affordable and I like some of the different choices and things like that it gave me. So that's my big today is photo work.

 

Christian Wenz (56:11.018)

Excellent, and last but not least, Scott.

 

Scott Arbeit (56:15.337)

So I don't know if you've heard of this thing called ChatGPT. It's really, oh no, that's not it. I'll give you, I'll give you, I know I almost just took one, I'll pick two. One is Dapr, D-A-P-R, and I've actually written Grace on top of Dapr. I love Dapr. If you haven't looked at it yet, I really, really highly recommend it, Dapr.io. It's a wonderful multi-platform. It's a way to write your code once and run it on as many platforms as you.

 

Christian Wenz (56:18.006)

Really?

 

Scott Arbeit (56:42.953)

as you want, it supports over 100 different plugin pieces at runtime. One other thing I would like to recommend, and I'll take a shot, is a wonderful presentation I saw from NDC Oslo, where I presented also, if you want to find that video. But Lila Bougria did a wonderful talk on

 

tracing in a distributed system and particularly in a message based system. I think we're all, we all think about how easy it is to, to plug things in with things like service boss, event hubs, rabbit MQ, whatever it is. But tracing errors as they flow through the systems is really challenging. And she did a wonderful presentation on, on how to tag those messages and how to think about tracing errors in those systems. I thought it was very comprehensive. So really enjoyed that talk.

 

Christian Wenz (57:33.906)

Excellent, great. Thanks for those two picks. Great episode. Thank you, Scott. Thanks for being with us. And yes, we did that. We certainly did that as well. And I hope you'll be back and really would be excited to talk about F-Sharp and the involvement and how you set up the grace system. All right, so that's from us this week. Hope you have a great weekend. Stay safe and...

 

Scott Arbeit (57:40.109)

Thank you so much for having me. I really appreciate it.

 

Scott Arbeit (57:51.68)

anytime.

 

Christian Wenz (58:03.208)

See and hear you all next time here on Adventures in.NET. Bye-bye.

 

Adam Furmanek (58:11.031)

Thanks for watching.