The Standup with ThePrimeagen - The Real Problems with Git

Episode Date: June 25, 2025

🔗 Sponsored by Code Rabbit https://coderabbit.link/primeagen-vscode ssh terminal.shop 00:00:00 - Intro 00:00:57 - The New Standup Dress Code 00:03:38 - What we're gonna talk about 00:05:05 - Code Rabbit Ad! 00:05:50 - Prime and Begin argue about Botched Rebases 00:09:21 - What Source Control *Should* Be 00:20:01 - Casey and Begin agree on the future Source Control 00:26:00 - Prime makes Git Branching even more Complicated by comparing it to Quantum Mechanics 00:27:56 - The Idiot's Perspective 00:34:00 - When Teej deals with Merges 00:36:48 - Conway's Law informs Git process 00:42:05 - Google Docs Analogy 00:45:30 - How Real Developers Ship Code 00:47:55 - What Should Version Control be? 00:50:54 - Would Casey let a Junior Eng roll their own VCS 00:59:25 - Why Prime Rebases and we all Fight 01:16:50 - Begin's Law 01:17:22 - Git Hooks 01:23:48 - Git Koans

Hey, TJ, we need you to lead today's stand-up. Bring us in, TJ. Okay, I hope this comes with a pay raise. Welcome, everybody. Welcome to today's stand-up. I'm Teage, today's scrummaster. With us, we've got, as always, KC. Oratory, Eagle Expert Extraordinaire. We've got Prime, Chief Entertainment Officer.

And because Trash, who is at Render ATL, hey, if you see Trash on the Internet, you can give them a little shout-out, say, Hey, heard you're doing a cool talk, tell them something like that. And then in the comments, say, Trash, give the talk on the next stand-up. True. We want to hear. We want to hear your good thing.

Okay? So let trash. Let him know you want to hear the talk. Anyways, in his place, we've got Began Bot, one of these directions. Who knows? Vegan, why don't you say hello? Oh my gosh. I didn't hear anything he just said, so his mic's broken now.

Okay. We're going to move on. Okay, so what is the topic for today? We're going to talk about Git. Yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, sorry. Well, first we're going to talk about why everyone is wearing a black shirt except for me. Was there some kind of memo that we were. went out before the standup that was like everyone

should look like Steve Jobs. Are you all wearing jeans at the same time? Like, what's going on right now? Okay, so TJ is fully in on the back. What the heck is going on here? Is this some kind of Apple like memorial thing? What is happening? You know, we just called

TJ a glass hole. That's all we do. Casey, have you ever warded a turtle like that? Is this the liquid glass right here? This is the liquid glass. This man's throwing some liquid out. Hey, uh, big We can hear you again. Say hi. You can actually. Casey, have you worn a turtleneck?

Because I'm going to be honest, I gave Teague's first turtleneck. He gave me this turtleneck. I gave him, because if you don't know when I travel, I usually carry a couple extra turtlenex in case my friends need to go out. And so he was like, hey, you want to wear one? And he's now been wearing them ever since. Wow. You feel different. That's why I was like, I'm ready to be the scrum master today.

This changes everything, Casey. So I feel like throw one on. You can lead the next standup. You know what I'm saying? I don't have one. I'm trying to think if I've ever worn a. turtleneck. You need to. Did my mom dress me up in one when I

was three or something? Like that's the only thing I can think of. It's never too late. Have you read that? Have you read the book series Miss Born? No, I haven't. And also, you know, I haven't ever I don't watch Elizabeth Holmes's fashion channel or anything. So I don't

really know that much about turtleneck wear. Okay, well, I was only saying that because in the second book, for him to become more kingly, he has to change his dress and accept it and often people will perceive you different. So TJ immediately has more authority than everybody else simply by the, you know, the dint of his clothing. Okay. Yeah, it's called aura these days, I think. Yeah. Okay. All right. Yeah. You can see your neck, no aura. If you can't see that it's the mystery. Why don't know? You don't have a neck. Like for me, I'm not really a neck,

a neck haver. And so it's, it's pretty difficult to see. Do you think people would say that when TJ puts this turtleneck on he has the Riz? Yes. Would that be something that's been said by the youth of today? Yeah, I don't think you

I don't think you typically put a definite article in front of Riz. He just has Riz. He has Riz. There you go. All right, anyway, today for some reason you guys want to talk about

Git is my understanding. Yeah. And we've actually pulled the audience for some questions. Believe it or not. And I have them pulled up. That's why

wanted to run this meeting today because I've got materials. Not in a slideshow format. They're just in like 37 different tabs. Okay. But that's just as good. That's what they tell me. So here we go. It's more than a phone.

iPhone. You know, that's kind of what I feel like now. Now I've got like slides behind me and everything. Yeah. So anyways, so we were like, we're going to talk about Git. We're going to about rebase, merge. I feel like initially, before we get to the rest of the questions, Prime, hit us with your hot takes about,

get rebase first get merge i want everybody to be fuming in the comments by minute five okay it's very very simple merge is for kitties rebase is for experts next question okay excellent casey any rebuttal uh my rebuttal is going to be towards the end of this part so okay we'll wait i'm gonna go and rant after this is is done and that will rebut all of the things that were said excellent Began, any thoughts? Rebase versus merch? I don't have to rebase or merge. I use the friend flag, and it always just goes through. Straight away.

Just throw that dash F. Everybody's your friend. They message you always right afterwards. They're like, whoa, dude. You literally see them, whoa, exclamation mark. Dude, exclamation mark, what did you push today? Question mark, exclamation? They're hyped.

They're like, wow, this is crazy. We're really proud of your progress. I always, I force push to every repo I get access to, to make sure they are either protected or they're my friend. You find out either. It's like friend classes in C++. Yeah. This makes more sense now.

Developers, are you tired of code reviews that just say looks good to me or here's seven things I need you to change that are irrelevant to the PR? We'll meet CodeRabit. AI reviews right inside your editor. Starting with VS code, cursor and windsurf. Sorry, no Vim yet. Hit review and bam. Outcomes feedback even before you open a poll request.

CodeRabbit can help flag bugs that you. your vibe coding with your LLM bots missed. And with one easy click, it can send all the context back to your favorite agenetic tools for quick fixes line by line. Code Rabbit offers a generous free tier with up to 50 code reviews per day.

Grab the extension now at codrabbit. com slash primogen dash VS code. Links in the description and ship cleaner code today. All right. So I've got a few questions here. We'll just go through them, see where we get to. Number one, from our lovely friend

Trash. I want to put Trash first because he was there. Why do I re-gling the repo after a botched rebase, which I knew would go great after Prime said rebases for experts. I'm not even sure what he, like, honestly,

I know Trash is trying to make a joke is what I think. I actually don't even know what he means by that. How do you botch a rebase? You never get like halfway through and realize you committed, like the wrong tree you checked in theirs instead of ours because they're backwards or anything like that? No.

This is seriously such a, how do you even botch a rebate? That's exactly what you botch. That is what you botch. That is the area where... Thank you. You dash, dash, abort. If you're in the middle of a rebase and say a conflict happens and you mess up the conflict, you're not in the right place, you do a little dash dash, you know, abort.

That's pretty easy. You can go, you can do a little reflog and go back from once you came. I don't know what, I don't know what the, I don't, like, what I, what I say I don't understand what it means to botch a rebase. Like, I literally don't know what it means to botch a rebase. Well, you can talk about getting a, a merge conflict and then not being able to resolve it, because you're going to get that merge conflict either way. Whether you get merge or you get rebased, that, that conflict's coming in. Began. Okay, I want to tell you what it actually looks like, let's say we got like a big old merge conflict. So many changes. Yeah. You're going through them all. You're sitting there. You're just, you know, you're, you're, you're D-Ding out. the little lines, you know, that's what I do. Okay. Okay. You're half paying attention. You got a podcast

over here. You're watching a streamer, you know. Some subway surfers. You did one file really good. You really made sure pulling those changes. Don't pull in those changes. Oh, I actually do want that change. The next one, you got a little lazy on. You got, and you messed up and all of a sudden you go, oh, no, I don't even know what I did. And so you could abort. I don't want to abort. I just, I did one, three files good, a couple files bad. So now I'm in this like botch rebates world. this happens sometimes what I'll do is I'll clone the whole repo. I'll save that state as like as as terrible botched zone. And then I will say, yeah, that's good. And then I'm with you. I know what's going to happen next.

Restart, copy files over from that botched one. It happens prime. This is normal idiot behavior. But I mean, but that, but that happens with merge too. Because merge, you merged. You got the same. You're over indexing on rebase here, I think. Yeah, you, you, you get the same conflict. And then you do the exact. same thing, which is you're doing really great on your first file. And then after that, you totally jack it up. But now you don't have an abort. I think you're getting over-indexed on the rebates. Trash is just saying he's just making the joke about recloning like Began is saying. I think you're overthinking this. Yeah, I know.

That's why I said I don't get it because of the rebate's part. See, I wasn't trying to be a jerk, Began. I'm just saying, I don't get it. Because it happens with merge or rebates. This is a not, you're focused on the wrong thing. I think Trash is over-indexing on the rebates. You're focused on the wrong thing. You're doing the thing of like, why would you need a debugger?

Don't write bugs. No, no, no. That is not true. What's happening here is trash is trying to make a joke and he knows people hate rebase and will be the most likely to agree with him. So he puts the word rebase after something that doesn't make it. Teach, do not like that tweet. Teach.

Stop it. Oh, my gosh. All right. Next question. What's the best way to deal with merge trains when you've, you know, so this is he's saying you have one piece of. of work, you break it into a series of nice, neat little tasks. Each

are individually cu-aed and reviewed, but they are depending on each other. Is Git good for this? Casey. Why are you asking me? Because I know. I just want you to keep saying, I'll rebut this at the end. I mean, have any opinions?

You have to, yeah, my opinion is that this discussion is why all this stuff is so freaking ridiculous. Like, the fact, like, your job is to program a computer. You're supposed to be spending your mental energy figuring out how to make good programs, right? And instead, like, 25% of every programmer's brain now is occupied with things like, should I merge or rebase? That even the fact that that is something that is now a discussion

means this was a failure. Source code control should be invisible, right? It should guide the correct process so that no one thinks about it. It just tells you what you know. need to do to do whatever it is that you're going to do. I'm just supposed to program. That's what I'm supposed to do. And then if there's a conflict, it should be like, okay, here's the thing. We send the correct emails. We schedule the meeting, whatever has to happen. That source control is supposed to facilitate programming. But instead, programmers are facilitating source code control. It's completely backwards, right? And so this needs work. People should be fixing this. instead of spending all their time arguing about whether you're going to rebase or merge

or what exactly you're supposed to be doing for large files, like, oh, do you guys use the virtual file system thing that they did, or do you use this other plug on how many? It's like, no, this stuff should have been solved. No one should be having a discussion, right? So perforce got it right? Well, Perforce is its own kind of pile. I would, like, Perforce has serious problems with large repos as well, like very bad. And so Perforce has some benefits, I guess you could say.

But in general, like, the thing that I wish people focused on was that source code control is not solved. Like, it is not a solved problem, not even close, right? It's like, we need people to be pushing this stuff forward because anything you look at is pretty bad when you look at what the optimal flow would be for people versus how much they're actually doing, right? So what is the ideal source control then? because honestly, like, in all reality, I neither think about merge nor rebase. I just operate in the way that I'm used to. Yeah, we know.

And that's it. And I just pull, push, that's it. And so I've never really thought much of it. I spend very little headroom to this stuff because I already learned it. So what does a transparent source control look like? Well, like, what we use here is one where literally I just type done at the end of the day. And it just sucks up everyone's work. that they've done and it like remembers the states of things and that's it.

And if two people have done something at the same time, it just overlays those two things. It actually just provides you copies of both and lets you know so that you can then go in and resolve those at your leisure or not, right? And that's just optimal for small teams because, you know, if you have hundreds of thousands of people, then you're not going to want to do something similar to that, right? But there's no benefit to something like Git for us because it's just a tremendous amount of complexity for no actual benefit, right? And you can add to that the fact that for a very long time, something like Git wouldn't have even been an option for people like us because we have

very, very large repositories, right? Even though we're small teams, when you work on art, you know, we've got many, many terabytes in our central server, right? And that's just completely out of the question for Git until more recently when they, you know, when they decided that that was something that people were going to actually handle. So in terms of the optimal source code control, the optimal source code control system, A, would just be something like what we use would be a setting you could pick. So you just like pick like we're a small team. So everything should just be completely transparent because we don't need any of, you know, any of the complexity stuff that a large organization would need. Everyone should basically not even have to touch source code control, especially artists. It should just kind of work, right? They just do their work and, you know, it gets sucked into a central, you know, versioning system for them. And they really don't have to think about it, right? And for programmers, it should just overlay the files. Just say, okay, someone else did these changes at the same time. You can resolve them at your leisure or not.

It's up to you. But I'm not going to bother you about it until, you know, you actually say you want to do something. And that latter point is actually pretty important to me. So this happens even to my own self. So if I have two different machines, let's say I'm developing on one machine and on another machine, and I make some changes that both affect the same file, right? I don't want it to tell me I can't check in. That's absurd.

Like, I don't want to create another branch. I don't want to have to do anything. I just, I made these two changes. When I typed on, I want you to back up what I'm doing. And I want that to be available on both machines. And I'll deal with it when I deal with it, okay? Don't stop my programming because you think your repository has to be in some pristine state. I know what I'm doing.

So just go away, right? So what I like is one where it's just like, I deal with stuff when I want to deal with it, not when the source control is. And I don't have to do anything to make that happen. I don't have to create branches or create different versions of things or any of that sort of stuff. It just works. My experience with Git and the reason that I don't like it very much is whenever I've tried to do even simple stuff with it, like pair program with somebody using Git, simple stuff like that, which is like, oh, I just want both files.

I just want to back up this thing. It's like, nope, all of a sudden you got to learn more Git stuff. Did you want to create a fork? Did you want to do this? You want to do that. What's your solutionist problem? I don't want to solve the problem, right? I just want you to back up my files and have everyone have access to those files easily.

When you're talking about a small number of people, none of these things are problems, right? We're not worried about, oh, we're going to break some thousand person org because somebody checked in like a slightly wrong file or something like that, right? So anyway, so Git to me is like it's not uniquely bad. I don't hate Git specifically. I just hate that we're still in this world where people can even have these discussions or all this stuff. Or that if someone like me wants to use this at our company, forget it. It would slow us down massively to switch to something like it, because it just adds all this process and all this knowledge people have to have for no reason at all,

especially artists, right, who they should never have to think about source control even existing because it's not really in their, they're not necessarily tactical people, it's not really in their worldview. So that's my opinion on this, and this is why I don't care at all about merge or rebase, because I think as soon as you have to ask the question, or even have two things, one called merge and one rebase, you failed. There's my rant. That's it. I got nothing else to say. I have so many questions right now.

Okay. Ask them. Okay. Go for it. Okay. So hold on. So you just have, you have your own custom CMS or a VCS, not CMS, maybe even CMS too. You have your own custom version control that you just type done.

Yep. And it puts your files up onto some sort of central repository. And any other developers, it also puts their clones up. and then everything that's not conflicted goes into like the super central repository that's like this is the golden standard now but anything where there's multiple edits you actually have like these two files and then until you need to re-edit it it doesn't it doesn't choose it like how do people stay in sync with like say your changes and my changes i'm just curious because like tj you know when we are working on more doryo it was really just like pushpole push pull push pull right we're like we're just staying in sync and we're not really like there's no actual get to it we're just you know the messages were crap it's not Like, nothing about it was trying to be professional. And to be fair, the only time that we had to deal with conflicts would be, like, when I chose to pull in your changes, right? So, like, until then, I was never experiencing a prime edited this file, so I can't do it.

So then it was fine. Yeah. So basically what it does is it just goes, okay, if two people have both made changes to the same file, they each keep their version of their file, and they also get a thing labeled alternate version in the same directory, It's the same as the normal merge of whatever the other file would be. The only difference between this source code control system and a normal source code control system is that's not a failure state. It's just like, we're going to let that ride.

You guys will work it out. So can you make edits? If there is an alternate version, does it freeze you from making edits? Nope. You can just go. So just keep adding. It will just track as many versions in place as you want until you guys have decided that you have collapsed them properly.

and you deleted those alternate versions, and then it will assume that you figured it out yourself. Because, again, on a small team, that's what happens. Normally, nobody should ever, and even this is true for a single programmer as well, right? Normally, I'm not making changes to the same thing on two different machines, right? But sometimes I am.

And in those cases, I just don't care. I don't want source code control involved. I'll deal with it myself. I just want source code control to preserve those things as long as it needs to, for me to get around to solving that problem, or someone else, if it's someone else's problem, I suppose. But that's what I prefer, right?

I don't want source code control to lock everything up and say, okay, nobody can, you know, you can't do anything anymore. You can't even back up your own files unless you create like a separate branch or something like this. I don't want that. I want to be able to just ride through this,

especially like maybe those changes aren't that integral. Maybe there was like something, you know, this other person was doing this not that important. We're just going to, that's just going to ride. in that side channel for a little while and I'll pull it back in when I'm ready, right? I don't want, I don't want source code control to insert a bubble into the process.

There's no need for it. And I can understand why giant orgs, you know, like I said, thousand people, you couldn't do exactly this. Although I think if I had to solve this problem at a larger scale, I bet I could do it better. Like, I could use this concept

and make something that would work better than the like, let's just stop everything from happening version. But I don't care because I don't work in a thousand person orgs. but for a single person, two people, four people, it's way better to just let it ride, in my opinion. Just let it ride.

Don't have source code control in the way. Just don't have source code. Don't have it be a thing, right? No, it's great. Casey, I think we have all the exact same opinions. Like, we should not be, as programmers, worrying about source control. That's why obviously AI is going to take care of it for us.

Because I're on the same page. That's right. You can commit, like, large things to repos. People get mad at me because I like to commit like 300 MP3s to a GitHub repo. Yep. And then GitHub says, Don't do that. We should be able to do that.

Of course you should. Holding us back. Of course you should. And yeah, just save every single version of everything we've ever done. Never ever. Yes. That reminds me of the of like it was either from Microsoft or from Dell when they were tweeting like, oh man, my computer's so slow. And then it was like, oh yeah.

And you have like 12 tabs open and Discord and something else. And they're like, why would you expect it to go fast? Yeah. Like we, everyone's like that stupid. Computers are fast enough to handle that. I do think it is kind of crazy that at least for a long time, I think it's better now, but like, we really can't just commit big files. Why does that have to be a big deal?

Or, like, that we can't commit, like, actual assets into the repo. That seems crazy there. So, I don't know. I, I, I like branching and, like, having branches and other stuff like that. Even at much smaller than a thousand people, like, even at, like, 10, I would definitely want something akin to like what Git has but I think G.J.

What? Oh yeah, I can go full screen, sure. Make yourself. We're going to go back to this later, but that's okay. Here, oh, this is just me. Oh yeah, there you go. Big me. But I feel like some

it was, Casey, in an alternate world where Git has like sane defaults has like commands that only do one thing. like checkout isn't like eight different things right yeah and like you're presented with like not silently pulling changes that you didn't know someone else made that suddenly like like you know I'm saying like in this alternate universe where I'm agree I agree with you it feels like a lot of

people saying well we have Git so version control is solved and like just because you have a command line thing that can do something doesn't mean that we've reached the pinnacle of that thing Right? Like, we can still maybe make it better. And yes, I know, chat, everyone's like, just use Jiu-Jitsu. Okay, we'll test it out later, okay? And we can get back to you about it, all right? Just relax. We know about JJ.

Just relax. Okay. But in that universe, Casey, like in this mystical world, whether that one exists or not, would you feel differently about version control? I mean, I've said what my thing is that I want, which is I don't ever want to think about source code control, ever, right? If I'm ever, if at the end of the day, I ever type something in because I'm like, I want my version control to save the work I've done or something. And anything happens other than I leave, right?

Then source code control has failed. Right? Like, I just type, I should just be able to type done, hit return, and that's it. And if there's any more work to be done, I, I just come back in the next day and I start working on that thing. It should not be like, oh, I have to worry now about doing something else to back up. my files, right, or to save what I've done. And a lot of times, source control, you do. Like, if you

tried to push your changes or something like this, right, so that they're available for other people, because that's another thing, it's not just backing up. It's like other people may want to access these files. If I want to push my changes, but there's a conflict, it's like, you really can't do anything other than say, like, okay, provide those

as like a set, you know, provide a different branch or other, like, no, I shouldn't even think about any of that. I should just type done, and I leave. And if there was some problem with that the source code control should just present that state to the other users of the system so that if they want to grab those files they can or if they don't want to they can when I come back in the next day, it will let me know about that. That's what source code control should be helping me, right? It should not be forcing me to think about what I am going to have to do

to make the thing I wanted to have happen, which is back up the files and make them available to people happen, right? That should just be automatic always and to the extent that I ever need to interact with source code control system, it should be perfectly prompted. So it should come back to me and go like, the next morning I come back in there, it's like, oh, hey, yeah, you two made these changes and they're in conflict. What do you want to do about that? Nothing

right now should be another option, right? But everything should still be available to people and they should be able to see those things. I want it to handle the problems for me. But what I see with Git 100%, but this is true of other source code control as well, so I'm not blaming Git specifically, is

that it always makes it my problem, right? It's always my problem to figure out how to put the source code control in the state that's most effective for whatever the situation. It should be doing that for me, right? And 99% of the time it should be able to do that because most of the things are not complicated. Like, they're not really ridiculous things, right? And usually what you see, and the reason this stuff does get complicated, is because the source code control is bubbling up its internal behavior to you. Like, it's forcing you to actually care about how it's actually storing things.

and how it's actually conceiving of things, but I don't care. I just want the state of my machine to be replicable to any other machine. I want my machine's stuff to be stored over time. I want to be able to get the what's on anyone else's machine. I want to have any two people who change at the same time be available to me at the same time.

I want all that stuff to be just smooth, and I never want to have to think about telling the internals of some source control system what to do to make that happen. Does that sense? Can I, can I, okay, so, Does this, what you're really trying to say is that you don't want to have to create branches, right? Because isn't that what you're saying is that your version is if you, you're kind of like on your own branch that anyone can look at. Right.

But it's almost like all branches exist simultaneously in your solution. Yes. Where it's like a quantum position. You can observe one branch. Yes. Experience it. But then if there's two branches in conflict, you can choose which side you want. And then you have, at some point, somebody has to resolve it, right?

If there is an actual conflict, which conflicts aren't too often, nonetheless, at some point when a conflict happens, you then have to resolve the two sets and say, okay, we're going to remove these two, like, competing things and turn it into one change, and then this will now make the branches effectively coexist in the same position. Well, and again, it's not like, I'm not asking for anything new, right? Because source code control, like, Git can already do all of the,

it can do all of the things that I'm talking about can be done with something like Git. It has the, I mean, with the exception of the fact that their large file handling always was very bad. So, you know, maybe I haven't ever tried the sort of new solutions that they've put in the past five, ten years to try and get it up to speed with that. So, but putting that aside, let's just say we're not talking about large files for right now. Git has the ability to do most of the things that you want here. So it's not like I'm asking for something. What I'm talking about is the appearance to the end user, right? I mean, I'm almost in a very unmee way.

I'm sort of almost saying like, you need the Steve Jobs of source code control someday to like come in and go, this just does what you want, right? For 99% of all the people, this does what you want without you needing to know anything, right? You don't have to learn some weird stuff

to like use your source code control. It just does it automatically with you never knowing anything, right? And any time that there's actually an action you need to take, it's clearly prompted to you, and it's really trivial for you to interact with, right? That's what I'm talking about, and you could build that on top of Git, although it gets jankier when you do stuff like that,

but you could do it because Git supports the fundamental operations that you would need, right? Did someone say Steve Jobs? There you go. Oh, go ahead, Began. Can I provide a countertake, yeah. I'm here to provide, like, the idiot perspective, as always here. It's like, I hear Casey saying, like, we don't want to have to think about this problem. I don't want to be the one has to think about how we merge stuff,

and, like, my VCS should just do it for me. Every vibe coder I'm talking to, they're, like, having a great time vibe coding, and then they have problems when they lose their code due to various vibe code reasons. The thing I end up warning everyone is you have to learn get. It's a painful part of coding life, but just like I don't want to talk to HR, but HR wants to talk to me every day. It's just part of what working other people. They love your jokes.

They love your jokes. They always want to hear them again. But if I kill it in a meeting, they invite me in every single time. So for me personally, I do feel like version control. is a place that it's supposed to be a problem. Because it's where code meets humans, which is terrible. If it was all code or all humans,

maybe we could get through it. But it's going to be hard. And I want to tell everyone, hey, vibe coders, this is going to be hard and painful and don't wish for something that's going to be better because this is the hard part of coding, which we can get around through two easy ways.

Number one, you make software with no other people. We're able to fix this problem. Just don't do any other people. And the other way is just we don't have to ship code either. I mean, I can just, you know, we can all be branching and just, so it's like, the more people we work with, the faster we have to ship, the more of this problem we have to deal with. And I just don't think, I mean, I think AI is going to obviously fix all of it very, very soon. And if anyone wants to sponsor the podcast, we'll tell anyone that it's going to fix it. I don't care what it is.

Like, there's things that could be helped, but this is, this is always going to be painful, is my theory. I would say, I think to like Casey, you're saying, get can already, it already has. all of the features you would desire in an ideal version control system in the sense that it can do all of them i don't want to be too stringent about that because i don't use it so like maybe that's not entirely true but i'm just saying yeah i know everything you've said so far definitely no he said something that doesn't exist you cannot have a multi you cannot have a multi branch universe in the sense that i can't check out a project that has everybody's distinct changes and then only in the conflicting world choose which person's side do I want to look at.

You always have to merge an opt-in. But you could simulate that using Git's branching features, I don't think you can't. What I mean by that is that I can't, like, you can't do that. Because if you have a set of changes that is different from like the core in sync one and TJ has a different set of things, I either have to look at only TJ's changes or only your changes. I can't look at all the changes except for the conflicting parts in which I have to choose which one. Like that does not exist in Git.

This kind of like quantum branching as I don't know what else to call it. Like you can't view everyone's changes except for the thing. It's funny it's called quantum branching because in my VCS it's called a super position. So it tracks superbizance. It's just saying like here's how many super positions there are for this file.

Like there's N of them, right? Yeah, I totally get this. It's a cool idea. It's a super cool idea. Well, thank you. I guess. But it's not complicated, right? It's just a it's a simple because fundamentally that's all a source code control system is doing. Is it saying, okay, I'm keeping multiple versions of things.

And so to me, I'm just like, why not also do that in time, in distance to time, do it in space as well, right? It's saying like, at this particular time, I can have multiple versions of a file as well, instead of just having it only backwards in time that I have multiple versions of a file. And again, like, I just, I maybe Git can't do some of those things, but I'm sure it's not that hard to imagine. extending get to do them, right? Like the idea of hash-based file stuff, it's like it could do this, right? It's not like it would be like, oh, my God, we have no idea how we could ever extend it.

But I would say even though, like, with 100 people, you can't do it in a practical way anyways without somebody doing something inside of it. Like, don't you think, Casey, like, even, like, your system wouldn't scale even probably like, at 100 devs working in, like, a medium-sized code base because there's going to be too too many overlapping changes, like, all the time, right? You'd have to do too many selections of the superposition at that point. Well, I guess I don't know because if you think about it. So, again, if I then went to a 100-person team and I watched how they worked,

I would probably have, I'd be like, okay, here's how we're going to do it, because it almost certainly wouldn't be what is happening with Git, right? So I can't tell you exactly what I would say you would do, but it's not going to be it. I can tell you that. And I suspect the superposition concept would scale. And the reason for that is that you might change a little bit, about how it's working, but the idea that you can, you already are saying that you're having multiple people

who might do overlapping changes. So by definition, you do have super positions that exist. They're just existing only on one person's machine because the other person can't see that change yet, right? And you're forcing one person to merge, and you're forcing them based on who happened to hit the push first, right? It's like somebody tries to push to the main repository first, so that person gets to push their changes.

the other person tries to push. They're like, you've got a merge cloud. You've got to pull first, right? And again, so to me, that's totally broken. I'm like, why? What if it was way easier to merge these changes in a different order, right? Why is my source control deciding that the way this is going to work is whoever happened to type push first on their machine?

That's the order that we're going to have our company resolve these changes. Like what? So I'm pretty sure I wouldn't have the exact same model as I have when you have just a small team where everyone's talking to each other every day and most of the people are doing art anyway

so you don't even really have much problem with these kinds of things. But it wouldn't be get, right? I would still have something that would probably have something with studio super positions. It would have a little bit more rigor to it

because I know that the people aren't in constant communication with each other, but it would not look like get still. I can guarantee you that it's just until I went and actually solve that problem, I couldn't take exactly what it looks like, right?

But I would say like, at least in my experience, like generally speaking, I only have to deal with merges when I'm deciding to put it into the same main branch. Like, in general, every place I've worked at, like we use, which this is not to say, get the way it's structured and the way that it's actually implemented

makes this easy or good to do, right, necessarily, right? But like, we would just have separate branches for each of the things that we're working on. You could do stuff like, get work trees that can make it easy to work on those same things at the same time on your own system and not have to wipe all the changes and even leave it uncommitted like in everything right and i can always push freely because i'm the only one pushing to that remote branch so like the only time i but you had you had to know all that right this is yes yeah yeah this is this is my right

yes my rant is then you had to do that right and and this is why i assume you know i assume and maybe this is naive but my assumption is that most places that use Git eventually like customize it like you just said, where they're like, okay, here's how we decided we're going to set up all of our stuff, right? This many repositories in this order with this kinds of commands that we use and maybe some scripts that do something for us or whatever else. They have all this stuff and then it does work for them, right? Or at least it works well enough for them, like ours works well enough for us, right?

But my point is that shouldn't be institutional knowledge, right? most things can be solved, I think, pretty directly. And that, like, you want something that just works off the shelf. So that people don't have to learn any of this stuff when they go to a company. They know they just type one thing in and it presents them with whatever they needed to do, if anything, right? And I, that's why I get so frustrated with source control. It's like, it just shouldn't be a thing, right? And I don't know.

Maybe that's just, maybe that's thinking that there's, maybe that's, maybe that's, that's, that's, that's, wishful thinking, like it's like, it's two pie in the sky, right? Like, maybe I'm just asking for something that could never be or something, but it feels achievable and the one we did works great for us. So I'm like, I feel like you could start to think about this harder and just start generalizing more and going like, what do teams generally want? Like, what is the thing we generally need? And is there sort of a more 99% case solution that's way better out of the box than

get, right? And again, there's still going to be edge cases. And there's still going to be people who would prefer Git because they've got some really special thing they're doing with it. And that's fine. But I think the majority of cases, it's just way more complicated than it needs to be and requires institutional knowledge to get it into a well-working state. Egan? Yeah, what are we going to say? Well, first of all, you know, to describe Git, breaking it down, we're using quantum mechanics, you know, analogies.

Like, we're like, Git is too complicated. Guys, quantum mechanics. Here's how we can explain it. That's scary, number one. Number two, I think to read what I was saying earlier, I think thinking about Conway's law and how it relates to get can, like, help a lot of this conversation because it's always about how the humans interact with the code.

So if there's two people, two engineers, and they're working in a similar code place, and they're sick of working with merge conflicts, you know what they do? They split the code up. They do it themselves. Like the code splits up naturally based off these, all this tension and who wants to work with who and what's going on.

That's why organization, match the engineers. It's like, but you can't, you can't like from on high say, everyone make the perfect best coat. It's going to go, dude, teach is taking forever on the logging thing. I'm so annoyed with it. I'm splitting out the service and doing it on my own. And then boom, now there's two different files.

It's like you never can prescribe what path engineers are going to go because we're all going to just go like, I'm annoyed, I'm lazy. Boom, split the file here, do this here, no conflicts there. So humans make everything so messy. And I just don't, we're never going to. replace humans. AI is never going to replace our jobs, ever, okay? So.

So, but so Casey, the only problem I see with your, the idealist approach you have, which, A, you still have to learn something, right? You still have to know that you have to commit, you have to say something to commit what you've done so other people can see it, and that you have to know at some point there's a divergence point. But like, you know, if Began says, hey, T's just taking too long, I'm going to create my own service, Bada Bing, Bada boom, pulls out part of whatever's T. T.J. is working into his own little universe and starts going.

Well, now we've kind of come into this point. where if Began commits this, it's almost like you want T.J. to be forced to act on that. Not that it's just like, oh, we can have two different versions. It's because, like, now there's such a drift in it that it's like, it's a for, like,

you really do want T.J. to know that this big thing has happened or else he's going to develop off that. And then that conflict becomes a way bigger deal in the future because it wasn't taken, like, it wasn't kind of like forced upon T.J. in its early conception. And that's the only thing I worry about is the super, I mean, I love the idea of just being able to view the repository as a series of changes from everybody.

But, you know, large organizations, obviously, you're going to have to choose like 10 super positions across all of them. Maybe you can do it automatically because you don't care about those other ones. You only care about your kind of silo. But at the end of the day, it just seems like Drift can be such a killer in this. Well, like I said, I think I would want to actually go design source code control for a large team first before I'd have like a strong opinion either way. because, for example, the superposition thing, I just, because you come up with solutions to problems when you look at what's actually going on, right? And this is why I don't like Git or use Git is because it doesn't solve the problems we actually have. So, like, let's say, you know, to take an example of drift in the art side of things, it's like usually they just have files that have artwork in them, right?

And if two people edit the same file, then all an artist wants is to know that there's files on their machine that have the work that they did and what other people did. and if they open up a file and it doesn't have the right drawing in it, they just want another file that's next to that file that does so they can go get it, grab it, and put the thing into where it needs to be, right? I also, by the way, I don't think art is good. Like, I don't think Git matches how art changes. Just to be clear, I think that gets a very code-oriented source control approach. But my point is that that's basically the same for, at least for me,

for when you're talking about relatively small numbers of people developing a code base. It's like, look, the way that, so the way the superposition thing works, just to be clear, is your machine always has your changes as the primary change. The superpositions are the ones that come in from other people's machines that would have overwritten one of your changes, right? On the other person's machine, they have their change as the primary one, and your changes are the ones that look like superpositions to them, right? and that's just what works most efficiently, even for me against me.

So when I'm doing like changes on two different machines because I just haven't sunk those machines in a while for whatever reason, that's just way, way better than telling me I have to merge something because I don't want to merge it right now, right? So what you're calling drift as a bad thing in a large org is a great thing in a small org because I'm not in the, I don't want to do the thing you're calling drift. I don't want to deal with that right now, right? So I just let it sit there and it's fine. And the same is true with the art side too. It's like if they don't want to have to deal with the like merging those two pieces of artwork, they just leave them.

And then they clean them up later, right? And this is just like, again, it's what you see people actually wanting to do. Like what is the actual thing that people want day to day? And only programmers want source code in their face, it seems like, right? They're the only people who for some reason think this is good and I want to interact with the lot, right? Nobody else ever wants to even hear that it exists. I'll say the distinction, though, I would say is like people, everybody uses like Google docs now, right? Like nobody edits like documents offline by themselves, except maybe like even my grandpa. He uses a, you know,

sheets now instead of itself. Like literally, you know what I mean? So it's like, I think the reason is because other like industries or professions, a lot of their stuff, like if you're right, or doing other things, it can work like independent of a bunch of other parts of the system, right? Like, I'm in the middle of like drafting a contract or I'm in the middle of like making a bunch of art. Like having one half finished art piece

doesn't make it so that I can't compile my booklet of art. I don't know what, a magazine, that's a booklet of art. Yeah, true. I've heard words before. But like for programmers, right, it's like, if I have someone else's half

done thing, I might literally not be able to run anything, right? And like, that's kind of like a feature in a lot of ways. Like, I don't actually want the code to be able to run with half broken, like, code, right? Like someone just literally wrote half of a C file. Okay, well, that's good. I don't want to edit it live in time. But so like I'm saying, so it is kind of different because like other professions, it's like, oh, well, we can all just iterate on the dock together. We'll work on the slides at the same time. We'll do all this. There is no, like, merging them in together, as opposed to, like, we're just. to programmers where we have to like force all of these things back into one spot. So I think it's like very different like in kind, not just because programmers like to make, um, you know, castles of abstraction, which is true, but like also we have a different problem set than like most other like industries. Well, sometimes we do, but a lot of times we don't, right? Like if you happen to be making changes to some kind of like centralized API or something, then I agree that you may have to take all the changes at once because, you know, you changed how some API worked and you had to change like all the places that call that API, right?

Yeah. But 99% of the time, especially on a small team, when you're, you know, you don't have enough people making changes to enough things to have a high likelihood of collision, a lot of times, no, it's just, it's fine, right? If you actually had something where two file, two changes conflicted on your machine, either you don't need to actually do that merge just yet, or it's very trivial for you to do it. So you have the superposition right there.

And if you have a compiler, you're like, oh, okay, I guess I'll deal with the superposition now. So it just ends up being the same as a merge anyway, because you can always just choose to merge those two files at that time, if that's what you wanted to do. But you're not being forced to do it. So the difference is just that Git makes you deal with it immediately, whether it needed to be dealt with immediately or not,

whereas the supervision version is just like, okay, you deal with it when you think you need to. And if you don't need to right now, then don't. And that's just better, as far as I'm concerned. Because why would I want to force someone to deal with something that they don't actually need to deal with yet, right? It's not like they're not aware of it. You know, they see the superbitions there.

They're like, okay, I know some people made these changes. I could choose to merge right now if that's what I want to do. But it's like, you know, and plus merge now is just something that is very obvious to them. They didn't have to ask to merge. They just see the two files and they can cut and paste whatever they want from them. Even if you never taught someone what a merge was, they could just do it because they know how to do that with files. So I don't even have to teach them like, oh, you're going to have to type get merge or something, right? Or whatever is going to happen, you know?

Okay, there's two quick, oh, sorry, go, go Began. You haven't. Okay, I was going to say, I'm a little confused case, because I've, maybe you're not developing how I develop, because the moment I write any code. He's definitely not. Yeah, I already know for sure. It's identical. The moment I write any piece of code, I write up a log statement, I immediately surround it in a feature flag. I get that merged in right away.

It's in production. I make sure I can flip it on and off. And then I keep developing. And so I'm merging, I'm deploying to prod, probably every 10. 10, 15 minutes, whatever I'm changing. And if anything breaks, feature flag. Is that how long it takes you to add a log statement?

Well, do, but the Docker build is slow. Okay. T.J., he's not using copilot. He's still manually writing slog statement. I'm mainly writing the console. What you meant is you asked the AI to, you ask Claude to add the log statement for you.

And seven iterations later it did. Yeah. All right. But, you know, but yeah, you don't have to, if you're always deploying, you're always synced up, you don't have to worry. You, it's annoying.

obviously because you have to deal with these problems all the time. But anytime I want to try any one of my features, we can do canary deployments. That's how Facebook works. I taught me this technique. Wow. That's really cool, Began. But damn, that's crazy. There's someone out there in the chat that is doing this process, though.

I had to do it at Ness all the time. Everything had to be driven through feature flags. So it's like every single thing I've ever done always had a feature flag first. And then I turn it on just for me and then you go blah, blah, blah, blah. All right. So two things. One, Casey used the word sunk to say that you had the sync to computer. computers. I haven't sunk yet. I don't know. I don't think sling slunk works in this case.

I still think it's actually just sync. I love saying sunk. I know. I just don't think it's, I don't think it's real. And I like saying macoss. There are so many things I like to say that you don't like. I can't remember what there was one other one too. I loved it. That's the fresh maker. Okay. I was on your team without a TJ that didn't like that. What was the other one? I had some other pronunciation. I can't remember what it was. Anyway, no, I'm the one that calls a Gipity. Not even Chad GPT. It's Gipity. So I, I, way off. Weasel instead of WSL. I call a Weasel because it fits both Microsoft and

it's kind of correct if you disemvaled it. Oh, do you call it like a seapoo and a G-poo as well? Dude, nobody love that. No, but we're going to. I'm about to. Okay. It's like we got to program this G-Poo to do some AI computation. Some AI computation.

Some A-competition. Okay, I do like some see-po. Okay, but the second the second thing is that I've completely forgot what I was going to say. I actually had a really important point. I can't remember. Oh. All right. Well, while you're thinking of that prime, I've got a few other questions. I really want to hit. We spent 40 minutes talking about this one, but not really talking about it.

I know, but I actually like this. He has like, why, why can't this just be like, what should version control be as opposed to Git? It's just like, I don't think Git's that great either, and I'm totally on your team, but, you know, we don't have to be like, what, let's answer questions about Git. This is more like, theoretically, is Git even good. And again, to be clear, I don't really want to, like, this was about Git, but. because that's what the episode was titled,

but I don't have any specific distaste for Git, right? I don't like version control in general. I think it is too onerous and puts too much, like, emphasis on itself. I just want, like, I want the modern versioned file system thing that's just, like, way less in your face and way less something that I think about, and is only there when something goes really wrong, right? It's like it's sort of the thing. It's like the safety net for me, right, is the way I think about these things.

And so a lot of ECSs, and it's not like it's just Git, aren't that. They're in your face all the time, right? And I also, so I do think there's also this sort of thing, Prime. But my chat's completely misunderstanding you. Casey's not saying he doesn't want to do like dot back files. He wants to develop things to be in sync. Okay, this is not final version V3. You're saying you're saying you want it there,

but you want it to be transparent as if we're all editing the same hard drive in some ethereal sense until you say commit. I want the magic, the magic server, right? It's like the magic server. And I feel like we could get there because like the little amount of work, I didn't spend very long making like our VCS is still crappy, right? It's like it's not some amazing thing that I spent seven years on in my PhD dissertation or whatever, right?

Dorin, it was only four days or five days. So everything is a piece of crap, so it's okay. Yes, it was a piece of crap. But I like it way better than any source code control I've ever used. To me, that kind of suggests that if I was going to go do like, let me spend a year making source code control things, to see what I end up really wanting and what's the perfect thing. I bet I could get pretty far, right?

And it sure wouldn't look like Git, I can guarantee you that. But again, that's not a knock on Git specifically. That's kind of broadly, it wouldn't look like subversion either, probably, right? Or, you know, whatever your favorite source control is. Perforce, I think, was mentioned before. I either used Perforce for a while, so that's why I did. too, actually. At Rad, we used Perforce.

Yeah. Yeah. I used CVS originally because that was the only thing that existed way back in the day. And that thing is a real pile. Like, GIT makes Git looks like a like a holy time. It's amazing, like, you know, compared to CVS. CVS was awful, right? I hate the pharmacy.

a big Walgreens guy. I get it. But yeah. So anyway, so nothing against Git specifically, just VCS in general, I feel like, has a long way to go. All right. So Casey, I got a question, okay? So you built your own VCS.

Nice custom for your cool work. Yeah, in close. Let's imagine someone new joins to work a company you're working at. How could they convince you? Hi, I'm new employer company. Hey, you're already using Git. Git, it's not good enough. I'm going to write my own.

Give me a week. I know I just started on the job. I'm going to build my own version control system, and we're going to use that instead. What would it take for me to convince you to allow me to do that if we were working a job together? I'm not sure I totally get the hypothetical. You're saying you're coming to the company and you want to write. Let's pretend. Yeah, you're using Git already.

I'm using Git. You're at a company where you're using Git. And I come in and I say, hey, listen, get, I don't know if it's going to work. I think we can do something better if I wrote my own. Give me a week. and I'm going to rewrite to our own version control. How would you be able to? Who could convince you to be able to do that?

Effectively, he's asking, how did you do what you did? Yes, exactly. How did you get it done? Well, just because I'm in charge, so I can do whatever the hell I want, right? I mean, but the point is that I don't think about it. I also don't think that's wise, right? In other words, I'm not suggesting, like, what I would prefer is that we took this seriously as a project, Meaning it's like we're going to go off and we're going to actually seriously develop a tool to do source code control in a better way, right? But of course, you know, I also understand why it doesn't happen because people don't pay for development tools, right?

So really the only way you could do this was as a SaaS, right? It would have, the thing that I'm conceiving of, there's no way you'd ever get funding to do it or to, it would never really happen in the commercial world without it being a service, right? So what you'd really end up with is something where you pay a monthly fee and then our company makes all of this magic for you, right? And source code just works for you, you know, control just works for you, right? Which, again, I would love if someone did that, right? I don't know that we would bother because, like, we have something that already works for us. But if you're talking about trying to solve these harder problems, you want to scale up to 100 person, 1,000 person, 10,000 person orgs. You want, you know, there to be some more flexibility to the workflow.

So it's not just, hey, what's the workflow? at Casey's company is the one that this works great for and it doesn't work for anyone else as, right? My point is just I'm just saying why we don't use one and why I don't like using Git and wouldn't use it, because it was very simple for me to make something that I prefer,

like quite a bit prefer, and for a bunch of other reasons too that we haven't covered, but they're, yeah, sort of minor things. I'm just trying to say, there's a junior dev out there that was me 10 years ago who would have said, I listen to Casey on a podcast. He wrote his own version of control. Can I write my own version?

control boss and they would say oh my okay HR you're fired it would be another HR meeting you're fired but but I mean to be feral all the people that are listening that have never dealt with large assets don't understand that before get a large file system came about it was a huge pain and even still then if you're on GitHub there's a whole series of issues when you're trying to do large files still it's not it's not it's just bad for a bunch of stuff you can't even have a big diff. I know. You can't even have a bunch of text on the screen. They'll be like, we're not going to show you that by default.

Or like Began had a long-running PR against one of my projects and rewrote the entire thing. But it literally said, infinity. It said, files changed infinity. Like, we'd put the infinity sign and said, whoops, are bad. We can't do anything different. Well, we lost that mission for rewriting an infinite number of files. We didn't, that's a pretty, that talk about a 10x program or that's an infinity X program.

are right there. That's why he's on the pod. Began has statistically significant size diff. Okay, that's what we're getting at here. No, I did commit 300 MP3s to that repo. Yeah, but that should... Casey's point is, right, and this is the separate thing. That should be fine. Like, we have computers that are fast.

That part should be fine. So I'm with you on that. Okay. My big question, sort of, I do still want to just run through a few of these other questions, just because we got some good ones from the comments. But I feel like a lot of it, a lot of Casey, your complaint with GitHub is not necessary,

or with Git, sorry, I just did the Zoom or things. There's all kinds of extra complaints you could have about GitHub. Completely separate, yes. Like, it seems to me you're not incredibly, like, opposed to an idea of like a directed, acyclic graph of changes that we can, like, move and merge back and do other. stuff like that. It's more that like Git should have like this. You type Git clone or something and it

gets you a new repo, sure, right? And then you say like, get new feature and you can work on that thing all by yourself and you can do anything. There should be like five commands that cover 99% of the problems and they should never error weirdly. Like in that world, do you think you would have used Git at your place? Assuming you can like do big files and stuff. I mean, it's really hard to say because it's about specifics, right? I'd have to try things. Because, like, I was very familiar with Git. Like, I've never become a Git expert.

Like, I'm never, I don't even remember half the stuff. Like, I look it up. I'm like, okay, I guess, right? And then, honestly, it's like, if it's anything complicated, if it's like, because I have to maintain the GitHub, some of the GitHub stuff that I have posted publicly, that's my interaction with Git nowadays. The only time I use Git at all nowadays is if I have to deal with something like that.

And, you know, honestly, if there's anything complicated, Like, oops, I did this thing and I need to remove it or something like that. I just asked Martins. I don't know if anyone out here knows Martin's Mosaico. He's at Rad and he's at Epic Games now because they got, you know, Rad got acquired by them. I'm just like Martins help me out. And he sends some, you know, large line with hexadecimal in it, right, and all this other stuff

that's going to do the thing. And I'm like, whew, I'm sure glad Martins is around, right? But again, that's also, like, I never have to do that with myself. If I just want to fix something, I know it's very trivial. in ours because we don't have things like having to put a bunch of hexadecimal into a command line to make something happen. But that's like an actual thing that occurs in Git, right? So it would really matter what the specifics are. It would matter how it actually works in practice.

And I'm just pretty doubtful that Git at this point would ever go in that direction anyway. So it would probably have to be some new thing or some really, really aggressively front end. But sometimes that stuff doesn't work. Like GDP front ends never are really very good. because just the underlying GDBness of it kind of makes it not happen. And I think that would probably happen with Git too. So I think you kind of need something

where the back end and front end are harmonious to really make something great, in my opinion. Yeah. And I feel like from Mizer, like I like at least most of the time like that I use Git, like compared to other options. Like I think it's good and like overall it's helpful. And I think I err more towards the side of like

I would rather get the conflict from someone else. his work like earlier rather than later most of the time just because it like it just ends up being a lot of the time it is not going to take me super long to solve the problem if I get it early but then it gets very complicated if it gets later like if we're we happen to be changing the same file and I like move a function down lower in the file and then like they edit the body of some other function in that and then all of a sudden like it's very hard to reconcile the things I would rather get those like as early as possible. So for me I would push like way further towards I would rather get that and have it interrupt my work earlier rather than later. So like for me at least on the teams and

the sizes that I've worked on like generally speaking that would be my preference. Although it's like different when it's like me and prime just coding one thing together. We pretty much just use it as like drop box. Yeah. Yeah. It's really a range. I used to see who pushes so that I was like, Who's the poll? I want to push first. Yeah. So, uh,

okay, so let me just, let me just do these quick and then we'll, that we got a few more here. Prime. Prime rebases because Prime is lazy, as is everyone who rebases. It gets rid of all the complicated merge history.

Yeah, who would ever want to know how things became the way they are? Oh, okay. Very simple. The reason why I do rebasing is, is, uh, first off, it's not lazy.

B, the reason why I do that is that I have a set of changes. I want to be able to be able to tell. test my changes on top of all known last changes. I don't want to test my changes in between things. When I merge something in, I don't want to pretend like where I tested it was in fact, was okay because there's new changes now. So I have to like know that what I did was correct in that position in time. Hence the reason why I rebase. What rebase effectively does for those that don't know, it's very, very simple. If you have a series of changes here and you checked out at some point in the

past, it takes your pointer branch at this and moves it up to the head. So that means I am testing against all known latest changes checked in and then my changes. And so when those are good, then I merge it in. It's really that. That's like literally the only reason why I use rebase over merge is because I don't want to be like, hey, everything's good at this point. Merge and then now something can feel broken because I can just merge it in. It's not a big deal.

Rebasing feels like I'm making a conscious decision saying my changes happened here and this is where I want things to happen. Yeah, I always felt that merge is more of a live than a rebase if you're doing feature branches because like I'm testing my feature branch on something in the past and then I want to merge it into something that's not the truth anymore. So I would rather test all of my changes on what it's actually going to be merged into versus what it was when I created the branch. Yeah. That's why that's what's going to be reality. Yeah. Began, you looked at me like I'm crazy. A couple things. Yeah. I'm with whatever sweet anchovy says, I agree, Prime's lazy. So I'm with that.

Okay. Well, that part, all right, that's a separate issue. Number one. But I think that there's like maybe a subtle difference here. Are we talking just a regular rebase or are we talking about a rebates maybe with some squashing, some rewriting of some commits, some chining up? I don't think it matters when it comes to your personal branch before it hits into the main branch. Obviously when we say rebase, we don't mean rebasing like the main line. That's insane. No one says that stuff. No, no, but I'm saying, I'm saying before, when you're rebasing before you're getting into the branch, are you going to say, okay, I've worked on a feature. I've been on a branch. I want to get it merged in now. I have 30 commits and half of them say whip, whip, whip, ah, ah, fixed, fixed. Yeah, yeah, I'm fine, squashing that into a single change,

putting that on top, doing whatever, making sure everything is to working the way I wanted to work, and then merging it in. I don't think there's a big difference between many commits or one commit representing some sort of feature, just because I rarely look at the past. And if I do have to look at the past, I'm usually bisecting. So 20 changes versus one change makes virtually no difference once you're beyond, what, 250 commits? So I will say, the chat immediately the messages are, please never squash. Next comment, Dax. Yes, squash. Yeah, chat's just wrong on that because they don't.

Dude, this is like the classic chat is saying words that they don't understand. It's perfectly fine for your independent feature to be squashed into its own. No, there's an argument for not squashing, because for, especially for someone like you, Prime, I want to see what you went through to get to this feature. No, you don't. No one ever added in. Yes, I do. I want to know how much frustration, how many commits are unhinged.

When I look and I say, okay, that's, okay, that's, it's not about fun. It's about knowing what's going on inside the brain of the coder who got this in. We're trying to put information about how we got there. You don't shake your head. He just writes perfect commit messages on the fly. No, I never write perfect commit messages on my branch. I write one commit message when I'm done or possibly two or three if the branch has two or three useful things that are distinct. Otherwise, I always write nonsense commit messages, squish it into one and then bring it in.

Okay. Everyone out there, everyone out of her who's watching this, this is what I'm talking about. 100% of everything that just got said, is not programming. That's the point, okay? And of all of this, anything you're thinking about in your head, re-basing merging,

where are the changes, how many squashes are we going to do? Like, you're not coding if you're doing that. This is why we need better version control. The fact that anyone even knows these things is a problem. It's taking up space in here that we could have used for programming. I'm going to say no, because they matter because it's how software goes from not existing to existing.

So I'm not saying Git or GitHub or GitHub pull request view is good. I worked at a company that was in some ways competing with GitHub and I was pleading desperately four months. Can we make a better workflow for this that makes it super obvious and easy for people? So like, I'm with you, GitHub workflow, it's trash. I want to review text. it doesn't show the diff, et cetera. But it does make a difference to say, like,

there are reasons where you would want to do both, and it matters. And when you work with, like, I'm just saying, like, it's very different. I think, like, Casey, what your, like, day-to-day thing is versus, like, when I'm working at a larger company. And, like, larger companies will continue to exist at least for a while, right? So, I mean, it's like, I think it's okay to have to learn some things. I'm not saying Git is the right necessarily abstract. for all of it, but thinking about whether we want to keep individual, like,

saves of your file or, like, squash it into one large thing, that's like a question for any system to change track, right, don't you think? I also, I mean, why would, like, if that's what you want, if you're worried about, like, what is the, the way in which you're going to present this information to the user later, like, this person changed their file end times. I mean, let's just, free yourself from thinking about how, things currently work and just imagine what did you actually want, right? Yeah.

And the answer is for a bunch of cases, you didn't want anything because everything just worked and no one's going to care. Then there's some cases where things went pear-shaped, right? It's like this stuff went poorly or something broke or something's weird and now we're doing archaeology, right? So now we've got to go back in there. What was this person doing? What's going on?

I don't understand this change or like everything broke and we need to like go back and deal with it, right? So there's different ways in which you might be looking. at this particular thing, but the one we're talking about is where someone's going to go back and look at this history because they're trying to figure something out. Like, they need some information, right? And if you're just talking about how many files do you keep inside there or what do you present to them as like as the forensic evidence about what happened, right?

Well, how often they saved the file isn't even that useful in that case anyway. I might just not push the save key very often, right? So what you really wanted anyway is just something that tracks all my edits as I'm editing, and I can just scrub the little bar back and forth. I can see how many times the guy compiled the thing, right, and how many times he ran it and what happened. That's what you're actually looking for, right? And the fact that now we've got like, oh, well, source control this thing is just like any,

maybe sometimes they save the file and it happened to hit push or something like, it's like, that's not even what you wanted anyway. So if what you're really looking for is forensics, okay, let's go implement the forensics. It's not hard. We could have a thing that just tracks all. all the stuff in your editor and it checks that in and that's what we have and if you actually need to go spilunky in it you go like like I don't think that I don't want the thing that you're saying begin what are you going to say yeah so you know a couple things I'm good because I have to

emphasize again it's like talking about how get could work without the human conflicting merging part of it it just can't exist it's like talking about the economy and saying and everyone will act perfectly rational and logically and based off that we can see the numbers are going to go it's like no but we're just talking about squash here we're right here right They're literally just talking about squash. That was what the... No, my understanding. I'm saying, sure. Even like I'm saying, like, squash, we're talking about, like, forensics.

People are not, it's not just saving. We're all as humans encoding information about when we are deciding to package things up. So, like, typically, if I might be doing 100 commits that I want to maybe squash later on. But those commits, I'm probably going to mostly have them be either if they're compilable, they're kind of working, or I'm going to put a note, hey, I'm going into uncharted territory. I'm about to break something. And so when you do that forensics, it will say, whip, I'm going into uncharted territory. Things might break here. And then you'll go below it and go,

hey, look, it actually. I'm able to find the bug that we're looking for forensically. Like, it's, it's about the human information we encode, not just me trying to say save. We all put secret messages to future us in our commit messages, especially sometimes when we're like not thinking and just frustrated. It's just trying this. Try anything. Trying this. Oh, cool. There were three messages that you said trying something. Let's work backwards and say, what were they doing here? None of these, you know, it is useful information, is my point. I mean, I'm going to go ahead and say no, I don't think it is. Like, especially because if that were true, everyone would be like, you know what,

comments and code are always right. They're always great. Like, the comments are always good. Like, everyone should comment all their code because it's never-sales. Like, no, comments in the GitHub repository are arbitrary. They're not checked by anything. They could be completely wrong, right? And also, you don't know that people were actually pushing at good times,

especially when you're talking about large orgs, like what you think all the developers are fantastic at deciding the exact right time to push something or save something. Of course they're not, right? A bunch of people forget or they don't know the right thing or whatever. So you're kind of talking about an org of only great people or something. No, I'm thinking opposite. We're talking the opposite. He's working the opposite.

Of course he's thinking of an org of great people. I'm being of the opposite. Humans are messy. I don't, I'm not telling you when right perfect commit messages, I'm saying the imperfect commit messages has the information we need inside of there. You know, when Teach starts a nice repo, it's a beautiful first commit message. six hours later it's ugh, ugg, trying, trying, ugh, and he go,

ooh, wow, maybe this is where things got a little bit rough. You know what I mean? I'm going after the imperfectness of developers. I think no one's going to do good. So I want to save all the information that they're spitting out into their... What is the information you believe you got from ugh? No, this is a part

where Teage was going off the rails. To be clear, I'm not 100% agreeing with Began here. I just want my... He does commit like that. Hold on. Time. Tia. Go, Prime, go. Okay, so the reason why, I think this approach that you're talking about Began is fundamentally flawed. It works probably really well in a very small organization.

But once you get to a large enough organization, I think there's something fundamentally broken about the idea of committing broken code. So I want every single point to be working. I don't want to bisect and hit weird cases that don't exist. And I'm jumping further back than I need to. Maybe I'm accepting incorrect positions. I want every commit should theoretically be working because the moment you don't have that, you break all sorts of other assumptions along with that.

So this is why I squash. I squash for the fact that this squashed thing represents my ideal change set for this whatever feature bug I'm working on. And it's supposed to work. Now, it may contain bugs. True. But you can then identify that that changes it. But again, it's the only thing that Prime is 100% correct on. Let's go.

No, no, not at all. Let's go, Doc's opinion. That is a stamp right there. Certified. No, guess what's going to happen? Prime. You're going to be doing beautiful, nice commit. The code's always going to work.

Someone's going to say, ooh, I actually did like five features over 100 commits. There's a lot of messy stuff. I'm just going to put them all into one nice. Yeah, and I say no. I literally say no when I was out a bigger org. If someone comes in with 15 things, I would reject that PR. Break it up. And you would tell them to deal with your crap.

Split it up and the commits. Yeah, you have to make individual commits because I don't want your crap because when something goes wrong. I don't want to undo 16 features if only one of them is the one, like one of them is broken. break it up be smart i'm not like mr atomic commits like you must have the most ideal smallest change that you ever have it's like at least come up with like a breaking point that's normal now again this completely changes when it's me and tige on mordoria i'm just working committing working committing it's smaller project we're meant to move fast yeah it's 30 000 lines of lua but it's still a small project easy to move on very different experience so it just totally

depends that's why i'm like on casey's team completely when it comes to what he's suggesting for a smaller team because I'm like, oh, hell yeah. If me and T. if I could just keep typing and seeing TJ's changing these files and then be like, yeah, I want TJ's files. Yes, I want TJ's files. Okay, yes. Okay, keep going, going. Okay, T.J.

I've synced up there. Oh, we just have a conflict. I'm going to keep working on mine. I don't want your conflict yet. I'm going to keep going. I'm going to keep going. I think that's totally cool. But a bigger one, I'm going to go with a much more stringent approach just

due to the change volume. Well, real quick, I just got to talk because it is Friday right now, and I just talked to one of our devs. He just rejected their PR. we were supposed to get that actually deployed before the weekend right now. And I was told by the dev, who you just rejected their PR, that you want them to just split up the files more is what you wanted. You do know what I do is I'd walk into their manager and say,

hey, your devs being an idiot right now, you are not going to let this keep going on our team. Either fix your dev or get a new one. We're not going to let this shit happen. Listen, you understand. I would be pissed if someone's deploying on a friend. Friday putting in 15 features. I'd be like, I am not being responsible for this.

This is your problem, your bomb. And if this goes wrong, I'm not even going to answer the Slack message until you fix it. Because that's not me. I'm not doing this. Okay, well, it's sad to know that you're not a team player. I heard Trash Deb was willing to actually do these commitments on a weekend. His name's Trash. Let me go talk to him.

Yes. You got to be the change you want. Okay. Fight for good stuff. Trash Deb is the promotion again. Can I, so the thing that I've. feel like is there's like the disconnect where I'm seeing is like I think and it's part of what like we're all kind of saying but it's a maybe a little different is like there are some things

that it is important for the developer to take time to think about and to do their own input into the system that can't just be from this is what I'm saying like it can't just be they save the file a hundred times or they ran a bunch of stuff like they need to encode some additional information into the system because that is going to allow us to either debug something later in the future. It's going to allow me to look at a big chunk of code together in a year from now and wonder how did this line get here. I can see that these changes were grouped with this particular logical thing. Maybe at some point we can get AI to solve all that for us or whatever. I know Began's ready for that to happen. But like that is additional information that doesn't come from

the physical, like, typing into the keyboard and running the code. And so in that world where I'm saying, like, it's valuable to have that and it's going to require some input, you will, at least in my mind, invariably have an argument between some people who are like Began saying, I want to see the ugs in this thing and prime saying, don't show me the ugg, write a good commit message with information and logically group these together. Possibly a version control thing could allow both of those. I was just going to ask that question. Can't we just have it so that the roll up includes the like drill

down if you want? That seems pretty straightforward. It does get really not allow that? No, there's no soft commit versus hard commit or whatever you're trying. I don't know what working is. In that world, the developer is still having to think about it and they will still have a disagreement or perhaps

something that they need to learn about how to do that. It won't be able to be like inherent to everyone and it will be very different at small companies versus big companies. Maybe. Maybe. I don't know if I really believe this. I am if for some reason

someone showed up and was like, we're going to give you $100 million of investment money to go build a source code control thing that just works for everyone. Then I believe we can do it. Because I've got the money. Then I actually like, okay, I bet we could

build this thing that works the 99% case and most people will just use it and the only super hardcore, really tweaky stuff will ever be done with Git after that, I have no doubt that you could, like, actually make the thing that just works. And granted, it has to tie in pretty hard to, like, the way that things work.

So, you know, you're talking about it, like, it's a pretty big project, I think. But I don't think it is, I don't think this isn't inherently difficult, or inherently impossible, is where I'm looking for, yeah. Problem. I think it's just like we,

especially because like the things that people actually want to do, they know when they want to do them. And they don't really need to be taught. It's like when I want to give my changes to someone else, I know that that's happening in my head. And I'm like, now is the time when I give my changes to someone else. So all the source code really should be doing is mirroring this.

It's like every time someone thinks they want to do something, they just push the button and it does that thing. Instead of what it is currently, which is when someone thinks they want to do something, they now have to translate that into what are, the series of getnesses that are going to make that happen. And maybe that's like, I'm going to squash some things and then I'm going to push it or I'm going to pull something first and then I'm going to rebase and then I'm going to do

this thing. It's like, no, I just push the button that's like it's time to give my changes and it does the right thing. And so I do think that's actually a solvable problem. Maybe call me an optimist in this one case, right? But I just don't feel like it's as hard as it's being made. Damn optimists. I think one of the, we'll make one, I'll never stop just fighting.

Yeah, we'll just keep making one more point. There's 30 minutes left in the video. You're the Git stand. Can we change it to Be GitGitstan? Be Git bot. I think there's a law out there. We can pick who to name it after. I don't know.

Trash is in here, so it might end up being Trash's law. Okay. The level of Git at your organization lowers to the level of the worst person. It's not one person pulling it up. Why isn't that Began's law? That's true for everything. That's not just Git.

That's everything. That's the educational system right there. And that's the problem. With Git, though, is that one person can mess it up for everyone. And then it's like, you end up, you know, putting all these things in place to handle the one person messing it up. So it's just, this is all for Dave. Like Dave, like, we had to do all of this for Dave. Everyone else was fine, but Dave showed up.

So, hold on, Casey, what do you think about commit hooks then? Like, given Began's law, commit hooks are effectively, I want to prevent. Not Began's law. It's Degon's law. It's, uh, it's Began's law. law. It's Began's law. You can still be smarter than everybody else. It's your observation, so you're the smart one. You can see the whole element. He's the one that keeps experiencing it. That's why it's called Began's law. Yeah. That's what we're going to tell him right now anyway. As we try to brand it Began's law. Or get hooks in general, the ability to prevent someone from even committing based on some state of your repo. Because there's pre-commit hooks that are like, sorry, you're not even allowed to commit. You have lent. Right. And then there's like, oh, you're not even allowed to put. because you have these things failing. I mean, you know, I understand what people were trying to do with those things.

I think if you needed them, then you're probably trying to paper over some problem that you have. Like you've hired some pretty bad people or you don't have a good training pipeline for those people. And so I get why you would do something like that. But my sense would be that if you're actually relying on those things, you have a deeper problem and those things aren't really going to solve that problem, right? They're just going to kind of make the problem almost worse because it's like now it's less obvious that you have the problem, but it's still going on, right? Underneath that there's the iceberg is still under the water line, right?

So I don't know. I don't want to say anything too strongly because, like I said, don't use Git, wouldn't use Git. But it sounds like if you were using Git and you thought that that was a good idea, you may, that may be. Every time I go into an organ, there's pre-put, like, any sort of commit hooks of any kind, or these Git hooks. You know that scene in Hot Rod, where Rod is sitting down and his dad comes in and, like, tries to insult him a little bit. And he goes, cooler heads are prevailing. And then his dad says, like, one more thing. And he gets up, goes, you're the devil.

and then like walks out and breaks the door. That's pretty much me every single time. Like, oh, yeah, get hooks. I could handle this. Do one single thing wrong, and I'm just like, you're the devil. And I delete them immediately and never respect them again. I hate them. I can't even handle it at all.

Like I said, I totally understand that I also understand probably what people thought they were doing when they put them in, right? Correct me if I'm wrong, though, but a commit hook doesn't have to be, like, a commit hook could be doing something beneficial too. like I'm going to go build this thing or something. It doesn't have to be bad. Can it only be bad? Only bad. It's only bad. Oh, sorry, you didn't type check.

You're not allowed to commit. So it's only ever for preventing a commit. It can't just, if you were triggering something off a commit, that's called something else. Yeah, I'm not sure if you can trigger. I've never thought about anything that triggers, like, say, formatting off a commit and then. Yeah. Could it never be something beneficial? Yeah.

It can't be beneficial. It could definitely not be beneficial or? it can be you can do you can do stuff like that like for example in our vcs right what we have is thing where when you check something in it does like you know keyword replacement and some things put stamps the date on things like stuff like that you can't something like that or it can do that do that so that's you know i mean that's not bad so there is there's a not horrible commit hook out there maybe somewhere no it's in the u-law they use the end user license agreement has uh has stated that it can only be used for evil okay fair enough yeah i understand i think the idea is like at what point does the code become shared by other people? If we don't think that like a GitHub branch is that, if I, because I don't like a commit hook that's going to prevent me

from being able to push to my own branch. It's like, format. I'm getting wild. I'm coding and I want it on GitHub. You can look at it. Why do I have to go and conform to your standards of prettier

while I'm getting wild? Shut up, dad. That's what CI literally is. I can put JavaScript semi-colons or not. Shut up, dad. Now, obviously, CI. I hate you. Slaps the door.

Yeah. It's my own styles. Seven spaces. Seven spaces. Fibonacci tabs. Seven space tabs. Yeah. Make it happen, people.

But you know what I'm saying? Like, it's really like when I don't, I only want to be prevented if it's going to get bad into a shared area. And I do not think that a poll request is a shared area. The only thing would be if you had something that could check for secrets getting accidentally committed. That would be good because we've, I've had it happen at a company before where we had open. source repos. Someone made a branch. Locke, like, they pushed. The end file never made it to production.

But it did make it to an open get repo. Yes. Whoopsy-pupsy. Now hacker found our Nfke. So there are a few things that. We're like, okay, I could be convinced. I could be convinced by that. Don't let me commit this. But yes. No, I think that are operational practices with you should be rotating all of your API keys on a regular basis. And so just having this be part of your operational

a regular workflow. Like, I think honestly you should be leaking API keys like once a week to just make sure the rotation work well. It's like fishing attacks. Yeah.

Have you heard of it? When I was at Netflix, we had something called Chaos Monkey. Yeah, yeah, chaos monkey would do. Yeah, yeah, that's exactly what I say. Yeah. It's chaos.

Yeah. We're just dropping our API keys regularly. I just made this one service. Does anyone on this podcast besides me not work for Netflix at some point? Is it just like you guys like this is the Netflix podcast and Casey? Yeah.

Well, like when I made this thing called Thalcor, it was literally just to stress test our servers. You know what I'm saying? Like, it wasn't for making features. That is actually pretty painful. We're not talking about jobs this episode, but I will give one piece of job advice

that I recently learned for anyone out there. Did you know that no one can stop you from adding anything to your Twitter bio? You can say I worked at Netflix and went to Harvard. But no one checks it. The amount of people getting reached out. It saved fine. So just a little job advice for everyone out there.

The amount of people I see posting pictures of being like, wow, congrats on being CEO of HTMLX from like a recruiter. Awesome. Awesome. Yes. And they reach out to Carson Gross and they're like, is this guy CEO of HTMLX? He's like, yes. He's the entire C-suite, in fact. All right, we got time for one more, right, TJ?

Yeah, this one is the one, this is one more that I wanted to give a shout out to Sphere. You know, he gets a little bit of flack from us sometimes online, but we'll give one shout out to Sphere here. Casey is directionally correct, yet also defends a worse alternative. Nice. So I don't know what that means, but we'll consider it a backhand compliment. Who knows? Also, dislike Git even beyond the obtuse cli. So the thing for this, sorry for blinding everybody, but I'm only a cord of the screen. This one, I feel like encapsulates very well a lot of the things that Casey hates about Git, where in the sense, like, you can get pull and then there will just be things merged in, but they're broken. It's like, why did you let me do that and said, there was no problem? Then, you know, you. It's like, how do I check out a different branch? Check out. How do I create a new branch?

Check out. How do I update components? Check out. What's the nature of Git? It's, you know, history is immutable. Oh, okay, splendid. So it's like, we merged these two things together. And then it's like, so these things never happened in the same time.

History is ephemeral. Or so like Git sets you up with this idea that it has a real history and then it just lies to you, right? Or like the Git tag. That lists all the tags. Get Remote dash V lists all the remotes. branch dash a does the branches and you're like can we not agree on like how to list all of something right like all these different problems does it also list all your remote branches as well and exactly so this i feel like this is where i'm i feel a lot of you know overlap with casey in the sense

that like git has a lot of arcane knowledge and there do exist a subset of people who are happy to know arcane knowledge just to know arcane knowledge and hold that over people and be like, you have to learn this. But I still feel like some of it, you have to make a decision sometime. And so you are going to have an argument. Like, prime people were just having an argument before this, uh, since we posted this tweet. They're like, just getting ready for the, you know, the squash versus rebase versus merge commit arguments because I believe and then they state a philosophical difference, not a

difference in the implementation of Git, truly, but instead a philosophical difference about how the history of a project should be represented. And that's where I feel like there can't be a tool that can fix that because people disagree. You have to have at least two, at least. And your company can use different ones. You know what I'm saying? So anyways. Agreed.

There you go. All right. That's it. Thanks for the comments, everybody. I do agree with H. I mean, the thing is, is I think we all recognize that much like democracy or capitalism, that it's a very terrible thing, but it's just better than all the alternatives currently that I know about until I see a better alternative,

I will accept it. It's the worst system except for all the others. Yeah, yeah. It's the when Churchill or ever said it's the worst system. Yeah, somebody said that. I remember this quote vaguely. Also, I will say for future episodes, I do not believe we should keep all of our commit history at all.

I am 100% on the side. I'm squashing everything, heads up. But if anyone does want me to represent an opinion in a tweet, You can just DM me, and then when I'm on, I will be your opinion. So just tell me ahead of time. But, guys, you do not want 50 messages to say, ugh in your repo. That's crazy. No, it's too late, Began.

No one's watched until this point. So they don't even know. Josh, cut this section out. We're never going to let people hear being in real opinions. Anyone who's watching live, I will tweet anything unhinged, and I will be you on the podcast until they kick me off again. Oh, man. All right.

Well, thanks, Began. Casey. Thanks, Prime. I hope everyone enjoyed this episode talking about Git and our wishes and desires for what version control could be. Maybe we'll check out Jiu-Jitsu or one of these other ones, and we'll come back with some better opinions later. Okay, bye everyone. Bye.