Coding Blocks - Git from the Bottom Up – Rebasing

Episode Date: September 12, 2022

It's time to understand the full power of Git's rebase capabilities while Allen takes a call from Doc Brown, Michael is breaking stuff all day long, and Joe must be punished.

You're listening to Coding Blocks, episode 193. Subscribe to us on iTunes, Stitcher, Spotify, wherever you like to find your podcast. Find us there. That's all I have to say. All right, good. It looks like these got changed around. You can visit us at www.codingblocks.net where you can find our show notes, examples, discussions, and more.

And you can send your feedback, questions, and rants to comments at codingblocks.net. And we got a Twitter over at codingblocks. And also we have a website, codingblocks.net. And you can find all our other social links that are up on the page. And as for today, I am Joe Zack. For today

you are? Yes. Tomorrow you're not going to be. Yesterday you might not have been, but for today you are. Okay, well, good to know. Who knows? All right, well, I am still Michael Outlaw. In a Fortnite, I'll be Alan Underwood. Nobody knows what a Fortnite is.

I know. Everybody's going to look it up. That's awesome. I'm going to go to the Googles right now. What's a Fortnite? Is that the game? Hey, so outlaw,

you go ahead and introduce us to this one. Seeing as all these are some of your favorite topics of all time. Oh, to the, to the topic. I thought you meant the top of the reviews. Okay. So,

uh, the topic, yeah, we're still talking about get, get from the bottom up. Uh, this has been a great free book available on GitHub by John. I'm going to try to get this right this time.

Vigley? No, Vigley. Vigley. Yes. Got it right the second time. First try. I was going to say, it seems to be pretty consistent. I think you're good.

I don't know why proper nouns hate me, but they do. So at any rate, yeah, so that's what we're talking about is Git. And from the bottom up, there'll be links in the show notes to the book and specifically to the chapters that we're covering in this episode. And yeah, as always, we'd like to say thank you to those that left us a review. So our newest review, which this one came from New Zealand, uh, and it's from now I practice this one. It's Emirate Shahal. Perfect. That's now for our newest, for our newest show segment, how it's really pronounced, brought to you by Alan.

Dude, I don't even know. I was looking at it going, it's a Mr. Itch. Ha ha. L. I actually didn't know. So, you know, I didn't realize it might be a full name. I think I got it. I think you were probably closer.

I think this time I nailed it. And so, you know, I feel good about that. Like, you know what? This is going to be a good episode. We're off to a good start already. That's right. Yeah, it was really – I don't know if you saw this one, though, but it was really funny because his complaint was specifically with me.

So, you know, I mean, I kind of had to take it hard because it was specifically with me. And the complaint was that there weren't enough dad jokes. So he gave us one to start it off. And, you know, I thought we would run with it. Right. I like it. Why did the dad wear sunglasses while telling a dad joke? Features too bright. I don't know. To protect himself from sun's glare.

Oh, geez. Wow. The perfect dad joke. Yeah. Yeah. That's good. That's,

that's a, that's a dad joke for the whole family. That is, I made a dad joke about a dad joke. That's right. Uh, all right. Well,

yeah. So thank you for that, for for the review we really do appreciate it all right excellent all right so to start this one off we are deep into the the get woods now and this one is going to be the power of rebase which uh i happen to love so i guess i guess we'll get into some of this as we go. So they start out with a little bit of general background just to remind everybody. So every branch you work on has one or more base commits, and that's the commits that your branch started from. And we'll get into how you have more than one here in a little while. It's actually pretty

clear once we get to it. And then there were a couple of commands that were worth showing. One of them I use all the time, and I'd imagine a lot of people do, and that's get branch, which shows you the branches you have locally. And then get show branch, which I don't know, maybe I've run if I saw it on a stack overflow and did some stuff but i've never run this no way okay i know outlaw has honestly no no really i i've never had a need for this this one and in fact um we'll get to it or i can go ahead with it but you know because the actual example that the author gave I found to be a little bit confusing with where my system was at when I was trying to compare and contrast the two. And, well, I'll go ahead and get to it.

Because what I found confusing is that in the example that he gave here, the commits were both the name of the commit and the name of a branch. And so then when he did his show branches, it was confusing because at first you're like, wait a minute, is he supposed to be showing the commit or the message? And it was like, oh, I see now there's a mixture of things happening there in his example. And so therefore that was part of what was confusing me. But also in my example. And so therefore that, that's what was confused. That was part of what was confused me. But also in my example, I had multiple, uh, I, he only has two branches in his example. And I had, uh, a third branch, which like added to, you know, the complexity of what that get show branch would, would give. But usually the git branch, like I actually do an explicit

dash dash list, but usually I use that command multiple times a day if for nothing else but for the delete. Dash dash delete. Same thing. I will do a git branch to find

out what I've still got hanging around so that I can do a git branch dash d or dash dash delete or dash D if I need to, a capital D. Now, I specifically don't do the dash D unless it's really, really necessary. So just for those who don't know, if you have a branch, if you do git space branch space dash dash delete and you give it some branch name get will delete that branch from your refs in your dot get directory and uh if if it hasn't already um but if it hasn't been merged up then it'll it'll give you a warning and say like hey this hasn't been merged anywhere do you really want to do that use a single dash uppercase d if you really want to delete it. To force it, right?

Yeah. Now, just a word of note, like where I ended up doing this a lot in the past, I don't do it so much now, is you remember OutlawJZ, I know both of you guys remember this. You remember when Azure DevOps introduced the ability to squash your PRs? If you did that option, it would change your commits that got merged into whatever branch you were merging into. And so when you pull down latest, when you do a get pull, it wouldn't see that your branch got merged in because the commits that actually got merged at the origin weren't the same as what were in your branch. And so in order to get rid of that branch, you would have to do a

forced delete because it would always be like, hey, this doesn't look like it's been merged yet. Are you sure you want to do this? And you're like, yeah, maybe I shouldn't have squashed it. I don't know. But, but yeah, so that's when I would use a capital dash D quite a bit. Yep. And squashing commits is definitely a good segue to get into talking about rebasing. Yes, yes. So real quick, let's talk about this get show branch just a little bit because it was interesting. I'd never really just sort of like both of you guys. I'd never really looked at this thing before. It basically walks you through all the commit history, getting up to your latest heads,

right? So if you go from the bottom up and, and we've got some notes in here, I don't want to go into it too deep because I mean, it's, it's pretty terse. Um, um, and it's not fun to read, but more or less, it will show you exactly what the original commits were that led into your branches and you can walk it all the way up to current right whatever head is did did you um did you guys try this on like a like a large you know heavily used repo like a work repo oh my god it would smoke your computer wouldn't it i mean it was it's limited to 29 branches. Yeah, it was, it was difficult. Yeah. There's so much that goes on. So in the simple little example that they have here,

and we highly recommend going to the reference that we'll have in the show notes here, going to that link and looking at the images and stuff that they show you the commits with the arrows and all that it's worth seeing, but it is a very small set of changes, right? Like when you start getting into things like what outlaws talking about, where you have a big repo, like this thing gets so nasty. Like I don't,

I don't know how you even traverse it mentally. Yeah. This is where going back to the previous episode, the different like way that you could name a commit matters because when you do this show branch command, the, the way it's going to name the commits will be like branch name, carrot or branch name,

tilde and some number, right? So that goes back to the previous episode where like, um, you know, tilde two, for example, is going back to commits from

the previous carrot is just going back one. You know, what's so awesome about that is I actually felt like I'd learned something cause I looked at, I was like, Oh, I know exactly what that means. Right. Um, because of our previous episodes where we talked about that stuff, um, because it's used in its own output. So it was pretty interesting. The one thing that like totally threw me, and this wasn't quite spelled out in the, well, this is where like the example that he gave here really cost me some time to try to figure out. That's why it mattered about the branch name

and the commit names, where he kind of like mixed them. Because like, that's why it mattered about the branch name and the commit names, you know, and like where he kind of like mixed them because like in one paragraph, he refers to like, uh, the letters because he just, you know, use a single letter for each one and he, he called them commits, but then he also calls them the branches. Cause in his get branch output, he's actually showing them as the branch names as well. And then, but they're also the commit messages, because when you do the show branch command, it'll show you the commit message that is, you know, that represents whatever that commit is, whether it be, you know, the branch's head or caret or tilde two or whatever, you know, it'll just show that.

And on mine, because I had a third branch, like, you know, I had, it tries to make columns for each branch and it uses a different symbol or color per for the symbol per column. Right. So that when you're looking at the output you can kind of see like which one it follows and at the top of the output is like the legend um which is like unlike most things right where the legend would be at the at the bottom and it quickly scrolls off the screen right so your legend's gone as soon as it's printed exactly you're like wait what just happened i got all these pretty colors and I don't know what they mean. But yeah, so it threw me because in his example, his bottom most one, which was the ancestor to multiple branches, right? He has it in brackets as branch name tilde three, right? He has it in brackets as branch name tilde three, right? Whereas on mine, the main trunk branch had defaulted to master. And so, you know, I didn't see that, that tilde three or, or similar

type of notation, you know, instead I just saw like the name of that branch. And that definitely threw me for a while trying to figure out like why is my output like why does he not have something like that why is his named like a tilde and a number instead of just the branch name so right so go ahead jay-z i was gonna say and uh we're uh we're trying as alan mentioned we're trying really hard not to read these diagrams off to you because it would sound like the alphabet song. There's a lot of letters involved here. And because of the branches and the commits combined, it gets a little tricky.

So we're going to try and kind of keep it light here. Did you all try actually working along with this, though, and try running show branch somewhere that was actually like a real code base that you're familiar with? Oh, I did, but I don't remember doing it now because it was like a week or two that i did it but i did do it and it was like that's when i asked like if you ran that show branch on like a on like a work type brand um repo because it it got hairy quick yeah and i noticed uh because i'm terrible about having to be in branches as i'll stay around that uh yeah it does limit it and so i looked at in 29 is the uh the limit that it sticks to um and it looks like there's some configs you can change that if you want to but i was trying to figure out what i would actually

do with this and i think for me it's kind of nice if you've got a couple branches laying around because you've been sloppy and you you're trying to figure out what those branches are if you're looking for something it's kind of nice people to say like get show branch and it kind of it makes it easier to see what was actually going on with those like much easier than just trying to go off based off a name depending on how you name your branches well do you remember alan's tip from like a couple episodes back i'll find the number in a minute but where um alan i think you said if you do a git checkout and you include a dash T, then it'll track the branch. And then you can do a git branch dash VV, I believe. Yes.

And then it'll show you what it was tracking, right? Yep. Yep. This is basically a way to get around to find that same type of information out, except it's still a little hairy to do it. Because when you look at that bottom most row, for example, and you find your symbol, you can see where all the symbols branched off of whatever the main trunk was. So in this example, his bottom most output there is where everything, because it has both symbols for the two, because he only has two branches. So since it has each branches represented by its respective symbol,

you can see that they both started from that particular commit. Like that's their, that's their ancestor. So it's, it's basically a way to get to what Alan was doing, except now also the downside is that, and I really thought that this was an odd and maybe even, uh, maybe like an inconsistent choice for the output because it seemed like it should have included, if not the full shawl,

like a part of it, you know, like it was odd that it was the message and just, you know, just the message i wonder i'm curious now to go see like what the full does it include the ability to get to the shawl all right so while he's looking that up and and trying to stay light on this we do need to at least talk about having at least two different branches right because the whole point of rebasing we need to understand what we're trying to do, right? So let's keep it simple. And let's say that we have our trunk, which we've talked about in the past, which is a terminology that's used with other source control systems. And then you have a feature branch, right? And they both, they both, you know, they started at the trunk and the feature branched off the trunk at

some point. So it has a parent commit that's on the trunk. So what most source control systems allow you to do is you work in the feature branch, let's say that you got 20 commits under your belt, and now you want to bring that back into the trunk. Typically what you'll do is a merge, right? And we've talked about different get flows in the past, like the, you know, where you merge features back in and essentially what they said happens here. And this is kind of interesting because I don't think I'd ever really looked at it in terms of what Git was doing behind the scenes. When you merge your feature branch back into the trunk, what it's doing is it's creating

a new commit that they said is basically a meta commit, right? They're saying that you're not actually making any changes to the tree, assuming there's no merge conflicts or anything. And so what you end up with is a commit that points to the latest head in your trunk into the latest head that was in your feature, right? And so that thing sort of is telling it how to merge, how to do that transformation to get back there. So you still have all your feature commits that exist exactly the way they were on that second path, right?

And then all your trunk commits were on that main line. And then you have a commit that points to both of those heads. And that is what this merge is back into it. And if I remember right, they called it, it was like the commit had like a prime sign after it, right? Like a single tick. So that's interesting, right? And they say, you can do that with every source control system out there. And you can also do that with Git. And in a lot of cases, you should do that with Git, right? If this is a public branch, something that's published somewhere, then you probably need to do that merge so that history doesn't change. And I'll let you guys dig into why that is. So I just wanted to follow up or close the loop on the show branch. You can say instead of the – if you use the dash dash Shaw 1 dash name, it will include enough of the uniqueness for the Shaw. So in my case, it's showing that in lieu of the

branch name so you either see the branch name or the shaw but you don't see both it's really hard to track something right it makes it it's definitely like a weird choice so i mean if i was in this position where i didn't do the checkout dash T and I'm like, Oh wait, what did I go off of? And I saw that commit message alone and the branch name, I might just rather than rerunning it with the Shaw one, you know,

I might just check out or, you know, uh, grab the log to see what the commit ID is for that message, maybe. But even then, I guess that would be kind of hairy in case if it was on a merge. I don't know. Maybe I wouldn't do that. But that's where my head's at.

But yeah. There are a couple of things that kind of tripped me up that I realized that I don't really have a great understanding of when it comes to commits and rebasing. You can imagine a scenario where I've got a branch, an outlaw needs to do some work, and he needs to integrate his changes with mine, but I'm not ready to merge my stuff in yet. So I say, hey, you know what? Why don't you just work on my branch a little bit, and I'll push some changes up there, and you can kind of use my branch for a little bit until we're ready to merge in. And then so we're both working out of kind of essentially a feature branch, you know, forget about it not being great practice. But what happens then is if I then go and do a rebase. You can't.

You shouldn't. Yeah, I shouldn't. You shouldn't. Right. I mean, the author explicitly calls this out as a scenario where you would not rebase. The scenario you're describing. Before you go too far with this, we haven't even really talked about what a rebase is yet. Yeah, we haven't gotten to rebase yet.

We're still talking about merges. Should we come back to this here in a second? Sure. Because this might confuse people if they have no idea what a rebase is. All right, what's a rebase? All right, so we talked about the merge, right? Which,

which takes that commit and points to the head of both those branches. And so now you have this, this situation where your stuff is, you know, merged. I don't like that terminology though, because it's, it's a commit that is the two combined.

It's how to transform them to where they work, right? To, to where whatever's in your feature is now merged on top of when we said feature and trunk, right? You're merging your feature into your trunk. And so that commit tells, um, get, you know, what it needs to do to make all your work in your feature branch work on top of trunk now, right? Like that's, that's your transformation. And again, the important part here is if you just think about two lines being drawn, right? Like trunk is your first line branch, um, literally branched off that and was a parallel line running next to trunk. What we're talking about is at the very

end of these things. Now you're going to have a commit that points to the, the end of both of those. So that's the important part about the merge, right? You still have two branches. They're still there. And then you have something that ties them together at the end. Now the rebase, this is where, this is where this comes in and visualizing those two branches is important because what a rebase does is you say, okay, my feature branch, nobody else has it, right? Like it's only on my computer. Um, I want to rebase my branch on top of trunk. And so what it kind of does instead of creating this, this commit that binds those two paths together, it tries to take your path and tack it onto the end of the other path, right? So your feature branch, it's basically going to try and take it

and stick it onto the end of trunk. And that is what that rebase would do. So you no longer have two lines, you have one line. And now it does do some changes to those commits along the way so it's not like it's just the same thing that gets put over there and again they rename their commits like you know commit with a tick um then another commit with a tick and i'm not exactly sure they're they're single single uh quote not a tick but because it's the prime, a prime. Right. So, so, okay. One, cause it's like,

this is getting a little hairy without letters in, in like, I see the letters that you have in the, in the thing, but I like there's better only cause it was like a single letter. But, and I know that we weren't, we said we were going to do this,

but, but just quickly, I just want to say this because I think it will make what you're trying to say a little bit sent that the one line, the trunk branch that you were just saying that you were talking about, like imagine that the commits on it to say a little bit the one line, the trunk branch that you were talking about, imagine that the commits on it are A, B, C, D. And on the branch line that you were talking about, imagine that your commits

are W, X, Y, Z. And so the difference there is when you did that merge where D and Z represented the heads of each, then you're trying to say Z plus D. But if you wanted to move... That's on the merge. Yes, that's on the merge. In the case of the, then you're trying to say Z plus D. But if you wanted to move... That's on the merge.

Yes, that's on the merge. In the case of the rebase, the reason why it's different is because you're moving it to where it's not Z plus D, it's W plus D, and then X, Y, Z, plus X, Y, plus Y, plus Z, right? You know what I'm saying? Because you're changing like where, where it's instead you're moving the ancestor for that first commit off of that feature branch. In this case, you know, in the example of the author, it was W. Yeah. You're basically tacking all your commits onto the end of the branch that you're trying

to move your commits onto. Right. That's more or less what it is, but then it rewrites them. Right. Well, that's why, that's why this matters because you're not like whatever your original ancestor was, and then you're doing your new commit, which is just the deltas from, uh, you know, it's just the change from like whatever the original ancestor was to what you're providing, right? You're changing what that ancestor was by doing this rebase operation. So that's why it, it matters because in the example that the author had where like everything originated off of a, so it was a plus w you're because you're moving that to D then. So this is where things get confusing. So check it out, check it out. I think maybe the easier

way to say this is, let's say that you had commit number one that started everything out, right? That's where trunk started. It was number one and you created your feature branch off commit number one. Okay. So both trunk and your feature branch, anything that happened from, from that point on commit to on the trunk or whatever happened in your feature branch, the ultimate ancestor was commit one, right? And so what Outlaw was saying a second ago is when you do a merge, whatever happens, let's say that you were 20 commits in on your feature branch. So feature 20 is when you do the merge into your trunk, whatever your last commit is on your trunk, let's say that it was trunk 20 as well. You're going to have trunk 20 plus feature 20, right? That's what your commit basically is.

It's pointing to both of those things. The big difference is when you rebase, if you had 20 commits on your feature branch, you're now going to have feature one instead of pointing to commit one like it was in the past. It is now the ancestor of it is trunk 20 because it was the last commit on the trunk. So you were basically moving the beginning of your feature branch to the end of whatever you're rebasing onto. Okay. You've now sold me on your, on your numbering scheme that you put in the notes here. And I'll tell you why. So in your trunk one and feature one, one plus one equals two. So you can see what that would be right so trunk one has one commit feature one has one commit and now when you do a merge of those

two things you're basically saying trunk one plus trunk feature one right but in your example where like trunk has moved ahead 10 branch 10 commits so it's now at T10. And feature, you've added five commits, so you're at F5, for example. So T10 plus F5, you can see that that would be 15. I'm trying to make this into a math equation. You see what I'm saying? Totally. And so now you can see that that would be different than if I were to move feature one to instead of being ancestering off of trunk one,

if I made it ancestor off of trunk 10, now it's, it's T 10 plus F one, which is 11, not 15. And that's, we have to stay, we have to stay out of it.

I know. So hard. I mean, talk about like rebasing without trying to like get into this. So that's the weird, but I will say, okay, let me, let me say this, though.

In a moment of embarrassing revelations that happened while reading this chapter, I have always questioned the choice of the word for this command, rebase. But now you understand why. And I'm like, oh, I get it now. Because you were previously saying this was the base of this branch. This is what its ancestor base was. And now I'm going to change the base to rebase it on something else. And I'm like, I don't know why that never clicked before. Like, why did it take this book to make that happen? Yeah. So, so rebase

really means you're changing the base commit for whatever the branches you're trying to move. Right. So in the merge scenario, you didn't change anything. All you did is you said, Hey, the head of my branch of my feature branch and the head of the branch I'm trying to merge into those things are now tied together via commit, right? You didn't move anything. You didn't change anything. You just linked them together. Yeah. You just have this like weird merge commit that is like how to do that. Correct. When you rebase, you are literally picking your branch up that you want to rebase onto something else. You're picking it up and you're tacking it on to the end of where you're trying to put it. And it's not as cut and dry as that. It's actually having to replay those commits on top of it to make sure it can stitch it together on that other branch you have. And that's why they say you should never, ever do this to a branch that is published that other people might have because you are changing those

commits. So going back to the Azure thing that I said about with Azure DevOps, it's a similar type thing. When you do a squash up there, when you're merging your pull request, it's rewriting the commits. So the commits that you originally pushed up, they're no longer the same because it's squishing all those things down into a single commit and then merging that into the PR. And so what you have locally no longer matches what's up on the server. Well, except like you're not wrong, except that gets a little hairy now because now we're like mixing in squashing, right? Because you don't have to squash to get into this problem. So back to what the author's recommendation was, any history, and I think we've even talked about this over the years, like any history that has been publicly shared, then you shouldn't rebase because you're changing the shawls.

And then you can't evenase because you're changing the shawls. And then you can't even push this up cleanly. Like you'd have to force push it up. And then when Jay-Z would pull down, like he would have problems pulling it back down. And this is why Jay-Z, in your example that you were trying to give about like, hey, you and I are sharing a feature branch and you want to rebase it.

This is why that would be so problematic. Like you and I would have to seriously coordinate that effort if we really want to. I understand. Yeah, I understand you should never do it. But I'm trying to understand what happens when you do do it, exactly what happens. So I kind of just set up a little test bed here and did a single commit. I see my content show up in the objects folder i do another commit and i see some some other stuff um you know i modify the same file and

so now i see a new object and if i do that command that we talked about last time what was it um read uh get cat file tell it's a blob and i look at the the uh the hash and i can see that it's a blob, and I look at the hash, and I can see that it's got the whole file contents there. So I can look at the first commits blob, and I see what I had for the first commit. I look at the second commits blob, and I have the whole file content. So it's not partial, right? It's the whole files content, just like we talked about. I can run get GC and clears up the old data.

So all of that is the same. So if we were sharing that branch now and then I rebased it, whether I, you know, whether or not I squash, if I just rebase it onto another branch, the file contents don't change. Right. And this is I'm not disagreeing with anything we've said so far. In fact, I'm the opposite. Everything you said so far is matches my understanding of it. it's just interesting to me that the file contents don't same don't change so the blobs are still the same the blobs are still named the same you know the the hashes don't change they're deterministic right based on the contents

what does change just like you said is the commits so if i uh you know squash for example then the commit in the chain of commits that kind of lead back to um where i branched off are different and there's no way to reconcile the commit hashes that i have with the ones that you have but i think though i think there's a difference here though because i think you're running through like a rather simplistic example. And I don't mean to like, you know, you know, make fun of your example here or like, you know, insult it. But the reason why I say that, though, is that if you were doing like if this was like, you know, things that were changing. Those blobs would change because the blobs never change. No,

I mean, no, let me, I'm sorry. Okay. I'm sorry. I didn't mean to say that. I meant to say that like the,

the ability to play yours on top of it, like the contents of it could be impacted. So you, you would, I wouldn't think that you might see a new blobs get created. Right. Well, I think the resulting blobs, right? So I think what Jay-Z is saying is,

let's say that you had 10 commits to get your file to the same state that he has one squash commit to get to. The ultimate contents are the same. I don't want to talk about squashing because that definitely muddies the water. Let's say that you both have an assignment. Let's say you both have a school assignment and you have to create a program that has a for loop that prints out a hundred things, right? It takes you 10 commits outlaw to get to that same thing.

And it takes, and it takes Jay-Z one commit to get there. The content of the file is exactly the same at that point. But your commit lineage is completely different right like he's got one commit and you've got 10 yeah and so that it's just kind of interesting to me to see in the objects folder that the the same object file exists so the same exact contents i can still do cat file on both of them because it's the same content at the end of the day and it's the whole content it's not a differential it's not based on what them because it's the same content at the end of the day. And it's the whole content. It's not a differential. It's not based on what came before.

It's the whole contents of the file. It's just interesting to see that, you know, just like we said, it's literally the commits that have changed. And when we've got two repositories, it's almost like you're comparing two different branches at that point. They just happen to coincidentally have the same name. Right. Your end result is exactly the same, but you couldn't, what you were saying earlier,

and I think where you were starting before we got into the rebasing thing was, you know, if you guys had both started off that branch at the same point, right? You created this branch, you pushed it up, and then Outlaw went to work, got his 10 commits in,

you went to work and committed it once you couldn't pull his branch anymore because it would jack yours up and he could not pull yours because it would jack his up they'd be like hey these things have diverged i don't know what to do yeah and it's ultimately because git is tracing the ancestry of all the commits. I guess what I want to be careful of is to say that like. Jay-Z didn't get new blobs in his example because it was a simple repo. Right. But in in your, you know. Day to day work life, chances are you would get new blobs created.

Like that's going to be more often than not. You're going to get new blobs along with those new commits because you're doing like, you know, whatever you're changing because you're changing the ancestor, right? Like the, the, the, the change to, to get from A to Z, you pun intended, relevant to the letters that the author used. But to get from A to Z, that path, those changes are different now. Those deltas might be different, right? The contents are going to change.

The contents change, but there's still still at the end of the day, Z, like whatever file it is, the entire contents of that file is going to have its own file in the objects folder. The blob. That's hashed. It's whole. It's not a matter of differential.

It doesn't build it up anyway. Like it's going to have a whole one. Yeah. And so I think what we're saying is, and I've seen this in Git as well, right? Like have you ever, I'm sure this has happened. You're working in your own feature branch. Somebody makes a fix to something that's broken in the branch that you had branched off of. And you go and grab their fix.

If you just copy and paste those changes into the file, right? Like let's say that there was some JavaScript file that was broken and you just go grab the contents of that copy and paste it into yours. It fixes the problem, right? You now have the same file that they fixed in their other branch. But when you go to merge that thing in, you're now going to get a conflict. If however, you had done a git cherry pick and pulled in that commit to fix that file, you would have no issues, right? Like when you go to push it up. So I think what Jay-Z is getting at, and correct me if I'm wrong here, I'm just trying to sort of reason out what you're saying. Even if you have the same contents of the file, if you didn't take the same git commit path to get there you end up having problems on conflicts with git

you know i i'm not sure exactly how the conflicts would pan out in that case it'd be it's such a weird scenario like i i i don't know how to tell really what would happen without you know trying it but the way i'm kind of understanding is basically it'd be like trying to to merge in two different branches at that point and so whether or not there's conflicts i don't i don't understand how conflict resolution works at this point um yeah and we lost alan because the 1980s called so yeah um i don't know if they heard that you know if the listener heard that but yeah, the 80s called. I think Doc Brown needed some help. Marty was out of some plutonium, and his kids were acting like jerks and all that.

Just to be clear, what you're saying, Allah, is along the way you're going to be generating different blobs because probably multiple different challenges are going to happen, so there's going to be more blobs, and there's going to be different blobs and there's going to be different blobs and just different scenario. But I'm just saying at the end of the day, the file contents are,

are hashed and stored, you know, for the whole file, not for chunks of it. Well, I guess, okay, fair.

I just wanted to make it explicitly clear though, that like I would expect to see new blobs get created based off of a rebase on a typical, you you know busy kind of uh you know your work type environment not in this case these small ones that we're creating to just run through some examples right well that's why you didn't see any changes happen but we need to keep in mind too right like there's a difference between the blobs and the commits right the commits were hashes of the creator. I forget.

There was a handful of things. Creator and date. Yeah. So your commit IDs, they basically said, will never be the same as anybody else's, right? So even if you end up with the same blobs, you're going to get a different chain of commits, even if you guys created the same five files exactly the same, right? Like out of some happenstance. So you're still going to get conflicting Git histories,

even if you guys are on the same branches, but you're doing things separately. So it's interesting. I mean, you're basically talking about having to try and merge databases and figure out which one wins. And that's a hard problem. And that's probably why there's issues when you do these Git merge type things. Yeah, it just kind of messes with my brain because if we're talking about a simple scenario where I do, you know, I know this is not to talk about squashing, but where I change history, but ultimately end up at the same spot. It's funny to me that the object IDs and the objects for the actual content is identical, but I still can't reconcile these things because it's two different chains. You

know, it got here two different ways. Exactly. And that's, that's what he was going at, right? Like no matter how simple or complex the repo is, even if you arrive at the same exact end point, but you took different paths, Git's not going to like it, right? You're going to have some work to do to reconcile those things. Yeah. I don't, as a human, you know, I kind of constructed this scenario and there was no way for me to fix it. So I could kind of see like, how can I expect Git to fix this automatically if I can't do it manually? You know, I've got I've got this number and this number and they're different. They don't match. And it doesn't matter that the contents match because I've got these two, you know, these two lineages that just don't come together. Well, I'll give I'll give you guys an example of something that's actually frustrating for me.

So in our in our work, the way that we the way that we do things in our day to day in order to deploy your code somewhere, you have to push your branch to the origin, right? And so typically when you do that, the whole, the whole notion is, Hey, once your branch is sort of off your local computer, you shouldn't do rebase anymore, right? Because somebody could have pulled down your branch and used it. But in order to deploy the thing, you got to put it up into the, the origin get repo. Well, I still will do a rebase because it's like, man, I only pushed it up here to see this thing work in a live environment, right? Like I'm going to go under the assumption that nobody grabbed my randomly named branch out in the middle of nowhere and used it. I don't know what you guys think about that. It's probably not the best practice in the world,

but unless I told somebody explicitly, Hey, go get branch ABCD EFG and try something. I'm going to assume that nobody did your thoughts. Yeah. I don't know. You're muted out. I don't know. You're muted out, though. I don't know why.

I was letting Jay-Z go first. I'm just waffling about. So, guilty. Okay, so you did the same thing. Good. All right. I mean, in my defense, the way I look at it, which is kind of similar to what you said, like if I'm iterating on a branch and I haven't asked you to go look at it and check it out and I haven't like said like, oh, hey, here, I've already made this fix and I've pushed up this commit. You can just cherry pick this thing and put it in your branch. decided to just randomly go and get my branch, like shame on you. Cause like I will, I often

will just delete the branch from, from origin just, you know, so that it's not even there anymore sometimes. Like, so yeah, I mean, don't, I guess, I mean, it's definitely, it's definitely not great and can get hairy, you know, I suppose. And it may be depending on like how much is hanging around on your get server. Maybe like, I don't know. Right. I mean when your work process forces you to do those kinds of things, like I don't know, you're right. I, you know, here's, here's one thing that I think that we need to mention.

Why would you rebase? We've talked about some of the problems that happen. We've said, hey, you should only ever do it if you're doing it locally. Why would you do it? I mean, in layman's terms, the reason why I would do it, let's say, for example, like, okay, first of all, let's get this utopian thing out of the way where like oh i i like work on one thing for a day and i like push it up and i merge it in that day and i'm done and then i i go home to the wife and kids and we have a lovely dinner at the table and then you know sit back and watch some johnny

carson no forget that like you know real life like you know you're you might be working on a feature and it could last like uh you know a week or two like you know it might list like if you're, you might be working on a feature and it could last like, uh, you know, a week or two, like, you know, it might list, like if you're on a sprint schedule, maybe it lasts your sprint, you know, like before you're like done in an appointed merge and I, yeah, that's somebody who's like, Oh my God, that's an awful idea. I get it. But, uh, you know, I'm living in the real, right. And, and so, uh, you know, I, I took the red pill. Oh wait, was the blue pill? No. I can never remember. At any rate, so the point is, let's say that I do live in this world where I'm not going to merge in for maybe a week.

And so on Monday, I don't have any commits being made. But on Tuesday, I do have some commits. Now, Jay-Z would have like 18 before lunch on Monday. That's right. Right. But but but, you know, maybe maybe I was being like a little bit more sparing with my commits. And so I didn't I didn't actually commit anything even locally until Tuesday. But, you know, in the meantime, like this is a work environment. So like Jay-Z and Alan and other people have made commits that have made its way into that uh, that have been merged into the origin because, you know, they're finishing up last week's stuff and just getting it merged in today, right. Or on Monday and, you know, after I've already done my pool. And so, so, uh, you know,

I get my thing in and on Tuesday, then on Wednesday, I might not do any, I might not have anything in a, in a commit state, but other people like Jay-Z gets another commit in. And then on Thursday, I put two commits in on my local, right? And in the meantime, Alan has also merged one in to Origin on Thursday. And now Friday comes along and I'm ready to do this PR and merge it in. Well, if I just did the merge and nothing else in the order that I just described it, then the commit history would read, let's say on Monday, I checked out and Alan was the last one to have merged in. Then the merged history, if I didn't rebase, would read Alan's

commit from Monday, my commit from Tuesday, Jay-Z's commit from Wednesday, my two commits from Thursday, then Alan's commit from Thursday, now my merge commit from Friday. Meaning that my commits are intermixed between all the other history that was in there. But that's not an actual realistic representation of what I worked on. Because when I worked on my stuff, I didn't have Jay-Z and Allen's commits intermixed in mine. Right? So, so it's kind of misleading if I just did a plain old merge of that,

you know, with my PR in there because I would be mixing my history in with theirs, like, you know, interspersed throughout it. And that's not how I did the development. So instead, what I can do, or what I do is I like to use the rebase option, because then, again, this is in layman's terms, right? I'm stacking all of my commits onto whatever the current head is, you know, and I'm replaying all of my commits on the top of it so that all my commits are bundled up together nice and neat in one package, assuming I don't squash, right? Because we're not talking about that yet. Then, and that's a better representation because in specifically the way I do it is I'll do a pull with a rebase option.

So if you do a get pull dash dash rebase equal true, then get will pull in the changes to your repository as well as merge them in with whatever the state was. But I don't want to confuse it in this case of like the merge that, you know what we're really talking about, but you know, it'll pull those in those changes down and then it'll replay my commits on top of them since, you know, whatever, wherever I last, whatever my ancestor was, it'll replay them from, you know, the new ancestor. Right. And so, like, I think it makes for a much cleaner Git log at the end of the day.

You know, uh, when, when you do that. So in short, I mean, this is exactly what I wanted to get at is the only reason and a really, really good reason to rebase is so that all your commits show up together, your messages,

right? Like started working on feature one, ran into this bug, ran into this, fix this, did this, whatever. They all show up linearly right next to each other in your Git log. That's the only reason to use rebase, but it's a really good reason to use rebase because everybody will get to see those things in that same order when it's done. I don't want to say it's the only reason to use rebase. I can't think of another reason other than lining your commits up so that people can see them in order. I can't think of any other reason.

Well, I mean, we're going to get into all the options that you can do with it. That's different. Those are totally different. No, but they're not totally different. They're part of the rebase command. They're part of rewriting history on top of it. But so that's fair. That's very fair. What you're saying of what we're going to get into after a minute here. So, so to, to restate what you said, then the way that the three of us have typically used it is nine out of 10 times or 99.99 times out of 100, you know, we're just doing it to nicely stack all of our commits together in the log before. Keep your work history together.

Yep. That's it. So that's it. And yes, that's a very good point. What we're about to talk about in a minute is going to stretch that a bit. But that is a very good reason to use it. Right. So,

yeah, I mean that I wanted to get that out there. So, you know, that there is a reason to use rebase instead of merge, right. So that you can get that nice, concise history.

So even though it comes with some downfalls or some things that you need to know about, knowing that you need to do it locally, other people don't have it and all that. There's a really good reason to do it. I mean, and if you imagine, you know, we're talking about just like, you know, a few developers here, you know, in this example, but you get into like a work environment where you might have hundreds or thousands of developers in there, that number of commits that might be between, you know, where you started from, the ancestor that you started from

and how many commits have been merged in since you know your commits throughout the week there it could be a lot i mean imagine like the size of like a google or a microsoft and you know what they're doing i mean i know that like google doesn't use Git, right? If I recall. Well, I mean, even on our, I wouldn't say we have a small team, but even on our relatively decent sized team, if you have two commits within the same day, there can still be 250 commits in between yours. Yeah, because we have like, you know, hundreds of developers, but I'm talking about like in a larger organization where like, you know, I'm thinking of like the windows uh right a repo right you know so it helps like it helps being able to put the the logical work together right and see how it went especially if you had any reason to where you needed to go back so now you've like merged your stuff in and you know jay-Z comes up and hits me up and is like, Hey man,

uh, you broke some stuff. Can you go figure it out? And I'm like, wait, how'd I do that? And like, and if I need to go back and look at my commits for any reason,

like it's a lot easier if they are, you know, conveniently stacked together, you know, Oh, there's my, there's my seven commits. I'll write one after the other.

I can see them cleanly. I'll write one after the other. I can see them cleanly. I'll tell you what does throw a monkey wrench into it, and it's really frustrating, is I mentioned that situation where what if you had a bug fix that was resolved in the branch that you grabbed from, that you branched off of in the first place? I had a situation where there was something like that. Somebody fixed something in that mainline branch. I cherry picked it into mine. Once you cherry pick, you're done. You cannot rebase at that point because if you rebase, you rewrite that commit ID as well. So it's a shared history at that point.

That shared history. I borrowed from somebody else's history so I can no longer do a rebase because it'll rewrite it to a new commit ID because it'll have me as the author. So, yeah, I mean, once you do that, you're kind of you're done. I'm actually kind of I'm actually a little bit surprised, though. I mean, I really I get that it's like shared. But when you do the cherry pick, right, like it's creating a new commit ID and would show, you know, well, if you used like the dash dash X option, right, like it'll It'll show in the commit message where it came from, but it's still generating a new commit ID. And that's the commit ID that you'd be changing,

not the one you picked from. So I'm surprised that that didn't. Well, I didn't do it on purpose. That was me assuming that I was going to mess something up. You have a good point. Maybe I could have. Maybe I will. I think you could have,

I think you could have because you're changing your commit. Yeah, my commit was already different because it was pointing, it had another parent and I'm not erasing that parent. Yeah, that's a good point. I may be able to redo it. We'll see.

Alright, I'm here breaking stuff all day, so just let me know. I like be able to redo it and we'll see. All right. I'm here breaking stuff all day. So just let me know. I like it. All right. Well, uh, let me, let me jump in here real quick. And before, uh, Jay-Z has a chance and say that like, if you haven't left us a review, um, you know, you want to hear more dad jokes, whatever, you know, I understand. I get it. Uh, leave us a review. You can find some helpful links at uh www.codingblocks.net slash review and yeah i mean you know tell us tell us what you want to hear we would uh we do really appreciate it i can't i can't say that enough so yeah and uh with that how about uh would you rather have a dad joke or just get into it?

Dad joke. Get into it, it is. All right. So it's time for my favorite portion of the show. It's still Survey Says, but now we're doing Google Feud for it. So no, I'm just kidding. Of course, I'll give you a joke. So well, actually, first, before I do that, though, I'll tell you something about german sausages i don't know because do you guys like those do you like german yeah but uh they're also they're the worst right dang it he already heard that one oh they're the first the first yes

very good all right fine spoil my jokes will you. I didn't think that would be really it. I figured it was one of those double ones. Double punchliners. Okay. That was good. I liked it. Fine. I didn't know.

Fine. This is a Jay-Z only. This is your punishment, Jay-Z. All right. What do you call a magician who has lost their magic? This match i was um jeez i don't know ian oh my gosh nice okay yeah magician minus the magic it's just ian

yeah all right it's not getting any better i was gonna be here for a while um okay so uh we're gonna play google feud your choices are and this is kind of like jeopardy though the way i'm giving you the topics i feel like i should read this in like a alex you know kind of like but always that also makes me think of the SNL Sean Connery skits. So your choices are culture, people, names, questions, animals, today's Daily Double, entertainment, food. Had to throw that in there. I'm feeling lucky or question of the day.

So this is episode 193. According to Tatako's trademark rules of engagement. Alan, you go first. So I'm going to go with the daily double. Let's do entertainment, please. Ooh,

entertainment. All right. Let me see if this one is a, I need to get to one that is acceptable. Um, clean. Yeah. I mean,

let me do this again oh wait wait wait wait wait this one could get hairy we're gonna try it movie about about um

oh nature wow nature nature movie about nature is not on the list jay-z about a boy was this like a Nirvana song? Also not on the list. Well, there's a movie called About Boy. Whoa. I'm glad you guys didn't get any of these because some of these were like really bad. Give us the top ones that we would have been able to say. Lottery and Elvis.

Those were up there. Oh, that's brand new. Yeah. Kurt Warner was up there. Oh, that's brand new. Kurt Warner was up there. Really? Alright, I could watch that. Yeah. Some of the other ones though, wow. I would have never gotten any of these though. Wow, mine are different.

That's weird. Is he doing incognito? Yeah, yeah, yeah. I'm doing incognito. Let me try this again. So, okay. So then,

uh, man, you guys are both zero for zero. So Jay Z, do you want to pick a, pick a category? Uh, yeah.

All right. Let me take a look at those categories again. Uh, you know what? This time let's go animals, animals. This could be bad too., let's go animals. Animals. This could be bad, too. Yeah, none of mine were really decent that I could say.

Yeah, yeah. That was unfortunate. So, can pigs eat diapers? I know what my answer would be diapers why would that i mean diapers the answer is going to be bacon that's what i would have said yeah so let's see oh my gosh bacon was not on the list really what can i then? It's got to be corn. I mean, chocolate was number one. Wow.

This gets dark. This gets dark. Humans is number two. I guess somebody watched Hannibal recently maybe. Grapes, then onions, bananas, banana pills. It's the same. Oh, it's the same thing as dogs. Oranges, potatoes, tomatoes, watermelons. Yeah.

Yeah. I should have known. I mean, bacon would have been. Bacon would have been the funny one. That's a good one. Yeah. Yeah. I guess funny.

I really want to know. Can pigs eat bacon? No one has ever asked about diapers, by the way. Of course not. that doesn't exist and the answer is google's like seriously you don't mean that it says yes pigs can safely eat bacon uh and that's ridiculous but but then is it right to feed pigs bacon of course not it says naturally it's a risk for any animal to eat the meat of its own kind yeah that's right it's just raw yes um yeah so there's your there's your google

feud that was depressing that did not work out well at all don't try any of those if you're at home don't don't try any of those yeah don't type those in those are bad yeah okay that's what i would have thought when you said those are bad okay okay that's what made me think of it i don't know why but okay so uh yeah wow off to like we're we're done with that weird dark tangent then and we'll just come back to get talking about uh rebasing so uh, the next chapter of the book was talking about interactive rebasing. And this is where, um, Alan's comment about like,

you know, how did you word it a minute ago? Like the only use for the only reason, you know, the only reason is to get your own get logs or your get commits in order. Right. Yeah. So this is why,

this is where, um, they, they, the author gives you examples of like why you might want to do other things with it. And specifically, like, I'm going to like go through these names real quick. The options that you have, like when you do an interactive bait, when you do a get a,

ah, I can't even speak this evening. I should have a podcast. So when you do an interactive rebase, what's going to happen is you're going to get, uh, you know, how like assuming you're doing everything through a command line, right? Then you go into these like, uh, you, uh, console terminals, you know, kind of UIs where a get does everything inside of like an editor, like a VI or Pico or whatever your editor of choice might be. Right. And, uh, it'll have, it'll have a command and then a commit ID and what the message, the commit messages for all of the commits that are in question here. And, you know, I'm not going to say like how you got to this command, like in Jay-Z's case, like, I remember

he says he just randomly goes back 20 commits and does his rebase which is weird don't do it that way is a good number don't don't do that way in the example that the that the author gave i believe his example was uh he specified a branch name am i wrong maybe he didn't even specify no he did he specified the branch name um that he was going to rebase but the point is is like you do a git rebase dash i and then some name of a commit which going back to last uh last episode you know there's a variety of ways that you can name in jay-z's case he's doing head tilde 20 um in the author's case he's doing the name of the branch. I usually just pick the SHA that I want to rebase to, and that's the way I've done it. Alan's giving me funny looks. I do branch.

The point is, that's how you enter that command that brings you into this terminal UI thing with these commands. And the commands are one of four things. Pick, squash, edit and drop. Now, just real quick, before we even get into this, like because you guys have done an interactive rebase before, right? Yes. Yes. Love it. OK, so that's three yeses.

Yes, yes, yes. We needed to know. Dang it. And three yeses. Yes, yes, yes. We needed a no. Dang it. Then we could have had yes, yes, no. At any rate, if you get that reference. Now, have you ever dot, dot, dot done a edit? No. Yes or no?

No, but now I would. All right. We'll get to it. We'll get to it. We'll get to it. Jay-Z? No. Have you ever done a drop? No.

No. Jay-Z? But now I would. That's three yeses for both of those. I've only ever used pick or squash. Now, in that example that I gave, pick is going to be the default command that's going to come up. So basically, like I said, it's going to be in the format that the terminal UI output is going

to be in the format of rebase command, which is going to be one of those four, the commit, Shaw, you know, enough of it to be unique. And then the message, the commit message that goes along with that. And by default, they are all pick. They're all going to be pick. And so if you just use the default, then what would happen is if you had, say, five commits that you were trying to rebase, then those five commits would all be replayed

on top of whatever the new ancestor is. They would be rebased on top of the new ancestor, right? Hey, so real quick, pause, pause. So what you just said is like, if you did a get rebase dash I, by default, it's going to do pick every time. It's worth noting, if you did a get rebase without a dash I,

it also does the pick every time, right? So that is what it's always going to do behind the scenes. If you don't do interactive, if you do interactive, this is the default selection, but you can also change it if you want. Yes. Very, very fair. Uh, and good call out. Yeah. But, um, so, uh, then, then there's the squash that we've already like hinted out a bunch and you know what, you might be confused, like, what would a squash do? Does it grow some squash?

But no, as the name might imply, you're basically going to like, in the case of your five commits, if you wanted all of those changes to be represented by one single commit, so that your history in your get log is super clean, then you would, you have to let that first one be a pick. But the others you could, after that, you, the next four in this example of five commits total,

you would say squash for those rebase commands, right? And at the end, when you're, when you exit the terminal UI, Git would then replay all of those as one whole commit together. Right. And you would get one, you commit, and it'll actually by default like show you, you know, it'll, it'll put all of the original commit messages in as one big commit message by default. Yep. You can, you can change that if you want. You can change the contents of the commit message if you wanted to. Um, but yes, that, that's like the way, whenever I have used the rebase, uh, option, be it interactive or not, like if it's one of those two pick and squash are

the two that I have used now. Um, and you know, like, are you guys, do you guys do this too? Where you're like, you're just, you fall victim to like, I have, I have a process. I have a pattern that works for me. And like, once I've established that pattern, like that's the way I'm going to do that thing. Right. And I, and I'm, you know, you know what I'm saying? What's that? Oh, yeah, there you go. Yeah. Like, like I was trying to think of like some, some other example and like the thing that came to mind was like, uh, I don't know, this might be a horrible example, but like if you were to play like a scale on like a piano or guitar, then you're like, yep, that's where I'm going to play a C major scale in this position. And that's where I'm going to start it.

That's where I'm going to play it. But yet, you know, technically on a guitar, like there's a variety of different ways or piano. There's a variety of different ways that you could technically get those same notes. Right. But you're like, this is my easy button. Like, here it is right here. I know this one like super well right yeah i think in terms of git i do it that way though because you know

that very well so if somehow you get in trouble you sort of know how to recover from it right like you you know what you need to do and and i think that is a lack of knowledge, which is what we're fixing sort of in this whole podcast series, right? Well, this whole podcast, this whole podcast has been a series of learning and fixing. Yeah. But yeah. So, so, well, I asked that because now with the knowledge armed with the knowledge of like, you know, the author putting in like the information for the edit and drop commands, then I'm like, Oh, that is super awesome. I've never even considered that. So let me, let me start with the drop one first. So here, here's the example. Have you ever, have you ever found yourself in a situation where you, you, you're working on something and you're like, you know what? Let me just change this one thing this way and I'm going to commit it real quick.

And maybe in Alan's case, he pushes it up to some repo or some origin or whatever. But the point is you've made this commit. And now you're like, oh wait, that actually isn't what I wanted. So you undo it, you make a new commit, and you go on about your day. And there might even be commits in between those two things. that actually isn't what I wanted. So you like undo it, you make a new commit, you know, and, and you go on about your day. And there might even be commits in between those two things. So it's not just easy to like undo that last commit. Right. Um, cause there could be things in between there. The drop allows you to remove that commit from the history as if you never did it in the first place.

So like maybe just to make a silly example, uh, you've, everything else is working fine. And you're like, oh man, I forgot to update the copyright date in the assembly info. So let me go change that. Um, 2021 and then you commit it and then you look at it and you're like, oh wait, silly. It was already 2022 and I, look at it and you're like, oh wait, silly. It was already 2022 and I changed it to last year. Oh, let me go back and recommit that to 2022, right? And so if you do the get rebase interactively, you could selectively drop in say those two commits as if they never happened at all you know uh which is awesome dude i can i can think

of a real life um example right off the top of my head where this would be super useful is in some of our spring projects because our our local systems have different home folders right there are certain file locations that are required by some of our spring applications. And every time these files, these, these apps get checked in the application properties get changed because people want to run things so that they'll work on their local. It would be awesome to just be like, Hey, I'm not going to check in the path to my local home folder again on top of JZs and then after outlaws and like we just keep stomping on them over time. I could totally see doing a get rebase and saying, okay, just kill that commit where I updated that application

properties file because it doesn't need to go up to the repository for the 500th time, right? Like it's a useless commit. It's a beautiful use of it. Yeah, so I thought that one was a super, super awesome one. Like it's for me where it came, would have been helpful had I known about it at the time. Like I didn't, this is again where I say that like, you know, you fall victim of like, you know your processes, you know, kind of thing.

And so like you don't, or maybe it's just me, like, you know, I don't bother to go back and look at like, Hey, I wonder what the new documentation is for the rebase command. Like, you know, I haven't looked at it in a while. And so I don't go back and look at it kind of situation. Right. Um, and so for me working in, uh, there was a period of time where I was doing a lot of stuff with Jenkins and the only way that I could make those changes was let me, let me make the change into the Jenkins file, push it up and then see if that worked. Oh, uh, that didn't work. Let me add this.

See if I like this better. Oh no, I don't like that better. Let me make a like this better. Oh, no, I don't like that better. Let me make a new commit to undo that thing because I don't like that better. And this is another example going back to your case of like, don't touch my branch because I'm going to like make some ugly stuff happen, you know, including like I might, you know,

delete the branch or force push it or whatever. And so now knowing that I could have dropped that commit, like I could have made a cleaner get history, um, when I was done with it all. So yeah, I loved, I loved that. Uh, I loved learning about that. So I really appreciated that one, but then there's the edit command. So what the edit command will allow you to do is let's say that you did make a mistake that you committed in. So maybe in all of that, you had a, you know, go back to my, my assembly info where I changed the copyright date and, um, you know, maybe I had other legit stuff in there, but that one commit in the middle of these five commits,

let's go back to my five commit example. And let's say commit three, I changed like, you know, a handful of files. One of them was the assembly info. And I, and I changed the date to the wrong date or the wrong year, right? I can put an edit command on that commit, which will allow me to change the contents at that point as if that was the change I originally made the first time. And then... It's like a cheat. Yeah, it's totally, it's totally, it's another way of like editing, you know, it's like editing,

amending a commit from the past, right? Except now it might not necessarily just be my last commit. It could be, you know, several commits back. And because I'm like doing this rebase operation, I have this opportunity to make all, to make that change. Yeah. And, and to tack onto what he's saying here, the thing that's interesting, if you've, if you've ever done a get rebase or a get merge, where you have a conflict, usually get will sort of stop in the middle of everything and be like hey you need to go fix this stuff right and then after you fix it you go in you

take care of the conflict whatever it is then you have to do a git rebase dash dash continue right and git gets basically like okay you fixed everything i'm going to continue on well that's what this git edit allows you to do except it forces that pause in the middle so what outlaw was saying is he can go in and change the year in that copyright. And then after he's done, he just goes back and says, get rebased dash dash continue.

And then get picks up and was like, all right, cool. Moving on. How awesome is that? That's just too well. Now here's where the author gave one that, that was kind of scary.

And I'm like, I know I can't think of any reason why I would want to do that. But he gave it as an example to reorder commits. But is he meaning, I don't think he's meaning in the rebase operation, right? I think he just meant like, in the case of like the the example that i gave where my commits are interspersed with yours i'm reordering them by putting them all at the end

right that's what he means right i believe so okay um i thought i thought you could move them around which was always strange to me but i don't know for sure in the rebase in the interactive rebase because how would that even look like what would that even look like as a user i don't you know it like it only makes sense to really do it to files that you know are are disjoint right like it doesn't make sense to to intermingle them wouldn't like you know it just seems totally counterintuitive to do it but i think that you can yeah he has it listed as a bullet point to reorder commits i i have no idea how you do it i i'm i'm going to assume that what he means there is got to be that in the in the

interspersed example that i gave before the reordering i'm doing it's instead of it going alan michael jay-z michael michael alan you know michael that it would then go going Alan, Michael, Jay-Z, Michael, Michael, Alan, Michael, that it would then go Alan, Jay-Z, Alan, Michael, Michael, Michael, Michael. Guess what? I'm going to do right now. That's what I believe. Because otherwise – He's going to break the matrix.

Let's see. I don't see how you – Rebase I, head to 20. Well, I mean, that's exactly what reordering commits is, right? Cause just what you said earlier, right? Your commits are out of order if you do a merge, but if you do the rebase, then you bring everything together. Right? So I think that's what that reward is.

We're about to find out. So I'm doing it so crazy. Make sure I'm doing this right way. So the reordering is as simple as moving the various pick commands around. So if I want to swap the first commit with the last, then I can do that. Now, while he's doing that, there are other commands that are given, like in the interactive shell, you know, that I was talking about, the terminal UI. So the author gave the big ones that you would use,

but I'll quickly go through the other ones. So if you wanted to reword your commit, there's a reword command and you can also like shorten these. So you could just do like a P for pick or R for reword. Um, we already talked about the edit squash. The fix up is like the squash, but you'll discard the commits log message. So I haven't used that one. Now I'm trying to think of like how that would work. So that would just being like, when I said before that by default,

it would put the commit message into the, like the squash commit, you know? So, so in the case of the five commits, and then you only, you squash it down into one. And I was saying that you would have all five of those messages in there. I believe what we're saying here is that it would discard. If you did a fix up, then you're squashing it, but you're also discarding that message so that it doesn't get

by default included into that commit message. Now there's an exec one here where you could like exec a shell command. I don't know. Maybe, maybe part of your build process is like you have some kind of script that would like automatically, uh, update some, you know, like dates for some reason, like, uh, you know, like in my assembly info example, you're like, Hey, just get the latest date. And like, you know, maybe like on a build server kind of environment, you know, I could see that kind of thing. Yeah. Um, so that's option.

Um, then there's the, a break command, which is to stop here. This goes back to your like dash dash, uh, continue type of operation. Uh, you'll, when you get to that commit, you're going to tell the rebase operation to break out of the session. And then you'll use the dash dash continue to continue the rebase operation. So maybe you had some reason why you wanted to interrupt gets rebasing so that you could inject some new commit or something. I, I'm not sure why of it.

I'm not sure of a reason why you would want to do that. It seems very much like the edit, right? Well, except the edit is, yeah. I mean, why couldn't you make a change and then do the rebase continue again?

I don't know. Maybe it doesn't pick up the changes and commit them at that point. I don't, there might be a difference. I do have a question for you though. So I was thinking about that. You had your, you had your five commit scenario that you're talking about and you know,

Hey, I screwed up with the wrong year in there. I'm going to change commit three, right? So I'm going to go into edit mode there. I'm going to change it. Then I'll do a get rebase continue. Right.

And so now you move on about your merry little way. You end with five commits that are all sort of stacked on the end of whatever you're rebasing onto. Cause I didn't do any squashes. Cause you didn't do any squashes. So the alternate approach here is you could totally just be like, ah, I screwed up. I'm just going to add another commit at the end. Right? So I know that I put in 2021, but it needs to be 2022. At the end of all this, I'll just add another commit and update the date to 2022. So now I have six commits. What's your preference?

Would you rather edit the one to get the mistake out of there? Or would you rather tack on a new commit and show that, hey, yeah, I screwed up a week ago, but I fixed it today. Well, in this very simple, contrived example, then who cares, right? I mean, it doesn't really matter. But I mean, you can envision a situation where maybe it is a bigger deal. Because here's why it would matter, where it might matter more, is that if you knew that that third commit introduced a breaking change maybe okay yeah if maybe your workflow uses the bisect operation then you might be more inclined to fix that third commit so that you aren't introducing assuming you're not squashing

you might want it you might be more inclined to fix that third commit so that you aren't introducing, assuming you're not squashing, you might want to, you might be more inclined to fix that third commit so that you aren't introducing a bisect operation. Because when you do a git bisect, you don't have control over where it's going to pick. And so in the future, what you don't want to have happen is git decides to pick, you know, some commit, and now that commit doesn't even compile. it's not and it's like this could be a year later so now you're like wait why doesn't it compile and it's not clear it might not be immediately clear to you that it's not compiling because a broken commit was added into the repo that's fair yeah that's fair so that's a good reason so uh i uh did a couple examples here i got uh answers so i was totally able to uh to move commits around so i was able to take like my last commit and put it as the first one for

example and if there was any sort of you know uh content that was conflicting basically you get a conflict and you'd have to resolve it as part of that rebase before it would let you continue with the own error. So I tried moving commits around the same file and, you know, conflict. If the files were unrelated, so like I added a new file and then I moved it down to my first commit, no problem. So I was actually able to swap in my first commit, like move, you know, my last commit down into my first, which is a weird thing to do, but it was totally fine. Wait, so when you did your get rebase dash,

I did it say like, Hey, which commit do you, did it ask you which order to do them in? Now it's what you do saying that he rewrote the, the list of commit of commits, right? Oh,

so you did it in that first pop up. Yep. Now you just like literally like copy and pasted that line from the top to the bottom or cut it from the top and pasted it to the bottom kind of situation which is the thing that it's metadata on how it's about to proceed and you just went and jacked with this metadata yeah it's really funny and why you could even add duplicates there and it'll tell you that that's not valid um you know then i had to google how to, uh, cut instead of just copying in VI. Uh, so, you know, that's why it took so long. Yeah. That's why I was saying like,

it depends on like what your, your editor is because I think I have like, um, like a Pico type editor come up as the default. I'm, I'm running through WSL. And so like just whatever was their default. And so like, I have the list of commands shown at the bottom that are all like, hold up, hold up. You don't use visual studio code. Really? For,

for, for my, for my get editor thing that pops open, like anytime that it's going to do like, um, anytime it does like the merge message for anything, it pops up visual. So I have visual studio code as my editor for get. So anytime there's anything that pops up, I mean, as much as I love visual studio code, I try to make it the center of everything of my workflow. Um, so yeah,

typically I use VI as the editor, but in this specific, uh, um i had it so it defaulted to like uh nano i think is what it's called yeah and so uh it's like remember like the old pico editor where it would show you like the all the commands at the bottom like it has that so yeah you know uh sounds like nano dude i love the studio code for that like i it it adds a little bit of a delay to pop it open but it's such a good editor for that stuff yeah so to finish out the the commands there you go tip of the week uh to finish out the commands they're there um we already talked about drop so now here here's a couple of others that like, I'm not sure why I would want to do this. So you can specify a label command, which is to label current head with a name. Uh, so if

you wanted to, I guess, I guess it almost sounds like that would be like giving it a tag, I guess, except it's not really a tag because you can also do a reset to reset head to a label well no that wouldn't be the same thing i'm mixing those two up but at any rate i haven't ever used those so i'm not sure like why i would want to label it but it sounded kind of like it would be similar to a tag at that point. Like what's the difference now? I kind of want to try it. I'm going to try that. Um,

and the last one, the last one is merge, uh, where you could like give it, uh, some commits that you want to merge in as part of it. So, yeah.

So let's see here. If I say, Oh yeah, I'm in Pico. so let's see here if i say oh yeah i'm in pico or you know oh geez oh gosh things are going sideways yeah i don't know how to pico yeah it probably is nano it is it is i keep saying Pico because that was like the old school one so if you give it that and then you say some label and then

you try to control X because you're in Pico I must have done something wrong. Cause it says that it can't do it. So that's, that's the takeaway now. Let's see.

So it gives me an option to say, edit to do. It helps if you spelled to do instead of with a b if you use a t um yeah and no i don't know it's not clear and i don't want to like waste time on it uh because i'm sure like listening to me type in the background. Isn't the most exciting thing. It just sounds like a little machine guns going off. It's good. Yeah.

It's relaxing. Yeah. This isn't even the good keyboard. So, I mean the, you know, cause this has a stupid blues, the ones where it doesn't alter your heartbeat every time you hit a key press.

Yeah. That's probably good. I mean, the reds are where it's at, man. All right. So, yeah, that'll be the survey. Reds or blues. There you go.

I think that's about it. We covered all this, right? I think we did. I think we hit it all. And, of course, we went in depth. Oh, man. I just realized it does say in the terminal UI messaging there, these lines can be reordered.

They are executed from top to bottom. So cool. Yeah. I mean, it truly is there in the documentation that you can reorder those commits. I can't think of a reason why you might want to. For fun now. Just to mess with people's heads. Yeah, that's it.

Like definitely change your commit messages to where they're like, this commit happened at this time of day. And then like, you know, reorder the commits so the messages stay the same. Totally. Although obviously you could just, you know, put your commit messages in like, you know, pick random times from the past to throw that off. Maybe that's a silly idea. I don't know.

Listen, you should probably just listen to John's advice on this. He wrote a book about it. How do you say his last name? Okay. That was how I was going to say it. I was going to say, John. That's exactly how you're going to say it is. Now I don't like the way you're laughing at me.

I was going to say John Vigley. Yeah, I got you. That's pretty good. You said it right. Thank you. I don't. Man, it's so hard. At any rate.

Just so you know um so you know for the record i've been uh googling why someone would want to reorder commits and i don't i didn't find an answer for that but i do see that pretty much everyone here is like get rebased dash i head till the some number oh garbage hot garbage don't do everyone it's like head till the three head till the four head till the five that's because they copied and pasted from somewhere else don't follow that advice yeah and here's for this it's like stack overflow it's just going to be like hey how do i uh reorder commits and the answer will be get rebase dash i till the our get rebase dash i head till the four just and they don't say why where the four came from they're just like let's just just try about four that sounds do that yeah you're good yeah man i'm telling you stack overflow can be dangerous

it's awesome all right so yes we have we we like. Um, they will be on our show notes page at coding blocks.net slash episode one 93. And, uh, now it's time for my favorite portion of the show. It's the tip of the week. There we go. Yeah. I'm sorry.

Like I, when you're reading, I saw, cause when he said, when he was said that I was like, Oh, you know what? I wonder,

there's probably like a quick answer on like stack overflow or someplace about like why I would want to use the label command. Oh my, there is not the answer. The accepted answer, like literally you scroll it and it's like 18,000 pages long. And now I might've miscounted one or two pages granted, but literally in the whole answer to this, and you do scroll many pages, the author of the answer only used the word label one time.

And everything else is just about, information about rebasing, but literally he says that he, he references that, uh, it's, it, someone else's comment is right. So he says that, uh,

it has to do with if you're rebasing merges. So it has something to do with rebasing merges is, is the takeaway from why you would want to use the label. I'm still, I don't know. I'm not doing that. Yeah. Now,

now I don't know. Like, yeah. At any rate, um, now I wish I hadn't Googled it. So yeah, we can't have nice things.

And now it's time for the tip of the week. That's right. So Jay Z, what you got? All right. So, uh, there's a band I've actually mentioned before on the show. And the name of the band is Russian Circles.

And I feel like, you know, that's kind of a topic these days. So, I did want to say that the band, their name has nothing to do actually with Russia. Other than the band name being Russian Circles. Apparently, it's just a sort of hockey drill. And the band even mentions Russian circles, apparently I said just a smoke sort of a hockey drill in the band. The band even mentions out on their Twitter account, but I haven't even told you why I'm talking about this yet. The reason I'm talking about Russian circles is because they are a fantastic rock band that makes a gloomy mid tempo and most importantly,

instrumental music. That's just perfect for coding. It's definitely got like a harder edge. So it's, you know, it's probably bordering on metal, but it's not super fast or kind of hectic. So it's really good for kind of focusing and concentrating, I think. So I'm a big fan of theirs. They've been putting out albums since 2006.

And I love all of them, including the new one called Gnosis. And so you should check it out because it's great for coding. Very cool. All right. So ironically, I started this episode with zero tips and panicking like, oh, there's got to be something. So I went and stole two off of Slack or I borrowed two off Slack, which I'll go ahead and mention first. Hey, did you take mine? off of slack or I borrowed two off slack, which I'll go ahead and mention first. Um, Hey, did you take mine? No, I think I messed up. I moved his. All right. So let me move his back down. All right. So the first one, I actually don't know how to say this name and I apologize.

Please reach out to us and tell, tell me how badly I'm butchering this. Thiago, they actually put one up here in our Slack channel in the tips and tricks or whatever it is, Slack channel, and it's called jsoncrack.com. And this one's actually interesting. So, you know, it's always nice to get your JSON formatted so you can see it, but this one almost breaks it out into like a graph. And if you go to jsoncrack.com slash editor, they already have a default blob of JSON in there and you can just sort of visually see how this stuff breaks out. And it's just a really nice expanding tree. Um, and it even has features to where if you click on any one of the nodes, it'll collapse and expand them and whatnot. So I don't know.

It's just really nicely done. So good way to visually see your Jason or Jason, depending on how you like to say that particular word. That's not really a word. All right. Then the next one, Jason, there's no a in it.

You say Jason too. Okay, good. I heard, I hear other people say Jason and I'm like like jason who um jason is a serial killer jason is a text document okay i like it or format all right so the next one i have is from larry weiss and this one's pretty interesting also from slack so thank you for dropping this over here if you've ever wondered what processes are like holding files open and it's driving you crazy, like you can see it in task manager,

but you can't do anything about it. Like you're trying to close something. It's like, no, it's open. Um, handle is something that comes from Sysinternals from Microsoft that you can install and it will actually give you more detailed information about the process that is holding something open. So pretty, pretty cool. And if you've never heard of Sysinternals, it's like a bunch of additional utilities that you can get from Windows to help you diagnose things and do things. So really nice. Go ahead. No. All right. Okay. And so that leads me to the two that I came up with here just a minute ago, as we were talking about some of these things. So personally, I love using visual studio code

for, for being my get editor, right? So like when you do the get rebase and it pulls up the thing that says, Hey, these commits, do you want to reorder them? That I'd never even read before. Usually that'll come up like outlaw said in his case, probably in nano. Some people probably have it set up for VI. I set mine for Visual Studio Code, so it'll pop up in Visual Studio Code. I can make my edits there as soon as I close that window. Then the command line picks up and goes to the next step it needs to do. So the way it works is when you have Visual Studio as your editor, it always gives you that sort of feedback loop.

Open up thing, make any changes, hit save, close it then and then git picks up and goes on where it needs to go so i've got a link go ahead there's an oddity about it though right if i remember right where like you have to completely close out of code before it recognizes it like it doesn't set file uh there's something no i remember like it doesn't cleanly pick up if you're using it for like your merge tool if i remember right no i use it for all of it it works great as soon as you close that file you hit save close that file then it picks up goes it is my daily driver has been for a while and and i remember i ran into something like i i was i was using it because you'd mentioned in a

past episode about using it as your merge tool and so i had to set up a new windows environment then you know day to day i'm typically on running on a mac but in this particular instance i needed to set up a windows environment so i didn't i was trying to install as few things as possible and i was like well i already need code and so I'll use that instead of installing K diff as the merge tool or the diff tool, I'll use visual studio. And I ran into some kind of oddity, I swear, where in Jay-Z shaking his head, like he's done this too, where when I made my change or selected my changes, you know, in the editor, it wasn't enough for me to close that instance because I already had like another instance of visual studio code open. It was like I had to close everything before it moved on and recognized it. Maybe it was a windows thing. Maybe

it was just at that time. Maybe they fixed, maybe it was a bug they fixed, but I swear there was some kind of oddity that I ran into. I mean, just so people know my workflow, I usually have like seven or eight visual studio codes open and it'll just sort of pop open usually to whatever the most recent one that I was in. It'll open up that file in it. And as soon as I close that file, then it moves on. So maybe it was a bug back in the day. I mean, that's my typical thing too. I typically have, you know, I try to use, look, I love visual studio code. I think we all do at least on this call, but, uh,

you know, because it is like a lightweight editor, I abuse the crap out of visual studio code. So, uh, you know, just because it's so, it's so nice and easy.

It's like, Oh, not only can I like browse the contents of the directory, but I could also just like randomly edit files or create new directories or files or whatever. Like, you know, it, it, it's, uh, maybe they'll just get rid of a file explorer and they'll only have visual studio. That's so good. That'd be kind of dangerous. Right. But I don't know you joke. I mean, all right. I'll, I'll say the other one here in a second. Um, so the other one is, and I think outlaws probably the one who brought this one up in the past, but I just wanted to redo this one is Gitlens. If you do any amount

of work in Visual Studio Code, Gitlens is really nice because it puts a lot of information from Git right there in the files. And you could see who last changed the line. They have all kinds of stuff. They even have visuals for the trees, the commit trees and all that stuff. So fantastic tool, but you joke about visual studio code is like your, um, explore it's even better in some cases, because if you have, and I think it comes by default with this now, I may be wrong. I can't remember, but there's the, uh, the communication thing to where you can actually have it open up a Docker's file system. So if you have a running Docker container on your machine, you could be like, yo, just open this thing up and go to the slash home directory.

And then you can edit all the files directly in there. You don't have to SSH in and VI everything. You can just do it directly. It's so good. So, yeah, that's it i think that's my 12 tips of this episode did you ever um did you ever try opening like a file from another like do you ever do like control o and visual studio code and like go open up another file as in another git repo and another git repo i don't yeah like what I have. So if I'm on my main code base, whatever, my main repo,

I might say open and open up a file on my computer that's just a local repository for keeping scripts and stuff. It's like a utility script. So I'll go in there and open up a file and do it. I've noticed the Git plugin on the left actually recognizes that one of the files I have open is in another repository. And so it actually shows another pane. So I can see the files for repository A and the files for repository B.

And I can commit from both, which I thought was pretty cool. I just assumed initially when I would open it that it was like opening and showing the Git repo just for where I open VS Code. But it actually inspects what files you have open and sees those changes too. So it's pretty cool so i can actually commit to my scripts directory or from my you know normal code base directory from the same visual studio code using the ui that's so good i don't think i've ever noticed that i don't guess i've ever paid any attention now in fact um that's one of the reasons why i have multiple codes open is i have like one for this

repo and one for another repo and same yeah like i never i never knew that but also like i do all my git commands through the uh command line not through the ui so i don't use git to do those i don't use code to do those type of commands but it sounds like you do i don't know sometimes i don't typically use it for commits but i definitely use it for looking for um changes since the last revision or who last made changes to a file like all those niceties are just well that's where your git lens comes in right right like git lens shows you that like super quick and easy yeah that one's pretty nice. And I realized that I owe you an episode number two.

So that git branch dash dash or dash vv command that Alan had previously given as a tip. And we've mentioned this one again recently, but that was episode 182. And also in the background, I continued looking into why you would want to use the label command. First of all, let me just say don't because, oh my, oh my, it is definitely about rebasing merges and you're basically labeling.

It's basically a way to like label that merges to to get to it i'm not even gonna pretend to say that like i know every i understand everything that they're talking about here because i haven't taken it i haven't fully grokked it while you know we're recording this but just that one portion of the documentation you have to scroll a couple times uh to get through it so yeah it's it's not for the faint of heart. And the reason why mine wasn't working is because there's additional commands that you would have to use with the label command

and like label onto, for example, or things like that. So yeah, it doesn't look like anything I'm going to be doing anytime soon. So yeah, so for my tip of the week, so I got a couple here. So first of all, from the Slack community, I want to thank Mike RG. He gave a tip for how to learn Postgres SQL in your browser. And this was brought to us by our friends at Crunchy Data, which I think maybe we've brought up before. I don't know. But it's basically like, do you remember Educative.io's kind of training platform where you could do everything in the browser? This is what Crunchy Data is doing for Postgres to where you can learn Postgres in your browser.

And you can see it spin up the environment and run through a series of commands to set up a database for you to start playing with. And where I think we might have mentioned Crunchy Data before if we haven't, but they have an operator for Postgres that you can use in your Kubernetes environment, which that's where I'm thinking if we would have brought up Crunchy Data, it would have been in regards to a Kubernetes conversation. But then I was surprised to learn that we hadn't already mentioned this one. So from our Slack community, Jonas BN

brought up the Divi Windows Manager for macOS where you can Divi up the screen for your different windows in a nice clean way. Because by default, macOS will let you split screen things

if you click and hold on the green ball of the stoplight in the top left of your window. And if you click and hold long enough, it'll come down with a little drop down and be like, oh, do you want a full screen or do you want this one off to the left or off to the right? And depending on which side you pick,

then it'll show you all your other available windows that you could in the opposite side so divi would allow you to if you wanted four windows for example um so yeah uh and i was surprised i went and looked and sure enough we had i could have sworn alan you used to use this uh app not divi i use another one. I can't think of the name of it, but yes. All right. Well, yeah, so that's my tips of the week. Thank you, Mike RG and Jonas BN for those. And yeah, if you're not already part of the Slack community, you should definitely pop in and join it.

You can find, there's a tips and tricks channel where you can find all kinds of great tips like that and more. And, uh, yeah, if you haven't already subscribed to us, like maybe somebody was like, Hey, you should listen to this crazy thing that these guys were talking about with the label command. Um, don't do it. First of all, don't the label command that is, but do subscribe. And, uh, you can find us on iTunes, Spotify, wherever you'd like to find your podcast. And, uh, you know, as, as I said earlier, before Jay-Z had a chance to make it odd, you know, if you haven't already left us a review, we do greatly appreciate it.

We really sincerely, you know, enjoy reading them. And it really does brighten our day with some of the stories and feedback that we hear from people. So you can find some helpful links at www.codenblocks.net slash review. Yep. And while you're up there, make sure you check out our extensive show notes, examples, discussions, and more. And if you have anything to share, please do on the comments here. And

please send your feedback, questions, and rants to our Slack community at codingblocks.net slash Slack. And if you're on Twitter, you should you should follow us and, uh, you know, tag us on stuff. If you, uh, make a cool project on GitHub or something, uh, give us a tag. We'd love to see it and share it out there. Um, if you do anything cool, if you make a, I don't know, a video or a post on dev too, or something, just, uh, let us know and we'll, uh, you know, send you a GIF or a retweet or a high five or something. Uh, yeah.

And we also have a website where we have other social links at the top of the page.