Coding Blocks - Understanding Git

Episode Date: August 1, 2022

After working with Git for over a decade, we decide to take a deep dive into how it works, while Michael, Allen, and Joe apparently still don't understand Git.

You're listening to Coding Blocks, episode 190. Subscribe to us on Spotify, iTunes, Stitcher, wherever you'd like to find your podcasts. We hope we're there. If you can, leave us a review. We would greatly appreciate it. And we're back to the old tried and true routine here. You know, the intro, the old old-fashioned, can we call it that? Although you did read the things out of order, which was really impressive because I would have stumbled all over that. Yeah.

So not quite the old fashioned. This is the modified old fashioned. Modified old fashioned. Old fashioned on the rocks. But you know what's still the same is codingblocks.net is 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 you want some tweets? I just tweeted right now. Just comments at codingblocks.net. And you want some tweets? I just tweeted right now.

Just tweeted on codingblocks.net. Wait, so, no, sorry. At. That's the one with the ats, right? At codingblocks. Also, we got a website. Alan already mentioned it. So I'm not going to tell you that again.

With that, I'm Joe Zach. And I'm Michael Outlaw. And I am Alan Underwood. See how I didn't try to confuse you this time? And by not trying to confuse you, it totally confused you? Yeah, totally smooth intro. That was great. Yeah, we were all slower there. Five stars.

All right, so Jay-Z's going to introduce us to this particular episode because I think he's the one who found the content. Yeah, but it really shouldn't be me. I think Outlaw should do this one. Really? Yeah. Okay. Well, we're going to talk in this episode about really understanding Git. And you might think you understand Git, but you probably don't.

You just don't get it. It's kind of surprising. You use something all the time and not really know much about how it works. And so it's kind of fun to kind of go back and look at a few things based on an article. I've seen a lot of commits that made me think that's just a way of life. Yeah, I've seen a lot of things. I've seen a lot of Git in my life. There has.

All right. So before we jump into it, though, we do like to thank those who have taken the time to write us a kind word or two. And Outlaw, I believe it is your honor and privilege to pronounce these. Every time. All right. So disturbedmime. Thank you. And also, um, I'm, I'm going to assume that this one will be pronounced Juco.

Yeah, maybe. Yeah. Probably. Yeah. The disturbed by him. One. Did you read that one?

I did. I did. It was pretty funny. Yeah. Yeah. He called out in there. If we don't have him as a guest on the show, which we don't typically do that,

as you know, having been with us for a while, um, he was going to drop our five star to a one star which would he would show us how important averages are over percentiles right so that was pretty funny um appreciate it yeah so well so much for that uh that great review that we had going on there. I love it. Stupid averages. Right. Oh, man.

I think it was like, I assumed he was referencing because iTunes, for example, and I'm sure other platforms do the same thing too. They show you the average of all the five stars. Even if you go to an Amazon purchase item right you see the average stars there so yeah yeah that's definitely what he's talking about he was going to try and drop us yeah oh yeah that was pretty funny um all right so this particular episode jay-z found an article by a guy named mark dominus where he was basically trying to give you tips for how to use Git. And just a preface for this show, his first part of his article is very short. And we'll get into that in a minute.

But he does give a reference to another article that we're going to sort of deep dive in this, which is giving you sort of the underpinnings of what Git is. So you'll understand the data structure and the model that's happening behind the scenes, because ultimately that will lead you to a place of understanding, which is where he arrived at. So just wanted to set the groundwork here. So it's kind of going to be split between two different resources, which we will have in the resources we like. But with that, we can jump in now. Alright, and so starting with the first part, kind of how to approach Git.

First point I make is that Git commits are immutable snapshots of the repository, which I, you know, I never really thought about a commit being an immutable snapshot of the whole repository, but I guess why not, right? It makes sense. It doesn't identify a file, right? It identifies the state at a given point in time. Right. And then the next thing you said, which again, I mean, I guess when you work with it all the time, you sort of get this, but branches are just named sequences of commits.

So you have hash ABC, then hash DEF, and then, you know, GHI after that. Those three commits, that branch is just, you know, hey, here's the first one, second one, third one, right? And that's what makes up your branch. And if every uh good no you go ahead i was gonna say every object has a unique id based on its content it's kind of uh i'm sorry yeah go ahead no no so this last one that he just said threw me off until i read further um the every object gets a unique ID based on its content. Hold that thought until we get further along.

Because when I read that, I was like, I don't really know what it's referring to. Um, but as we get further into this episode, that will become clear. Um, what were you going to say outlaw?

Well, the, the branch name thing though, as a serious commits, like, um, I guess he didn't really make it clear i don't if i recall i'm trying to go back i'm skimming it skimming back over it now i don't

think he like went into like a super lot of detail what he meant by that about the branches are named sequences of commits i thought of it more as uh a branch is just a named commit. So in that, in that commit can move over time. And, and cause even in the other, even in the other article that he referenced, get from the bottom up, they made a similar comment and they said that tags are also named commits.

The difference is that with a tag, you can't change the commit, right? Like it's, although technically you can, but. Well, no. So I think I know where you're talking about. So the branch being a sequence of commits,

like if you were to do a get log on a branch, you're going to see all the commit hashes that happened over time. Right. And so it's a sequence of them. If you were to get check out a tag and you did a get log on that, all you're going to see is that one commit ID so it's a sequence of them. If you were to get checkout a tag and you did a git log on that, all you're going to see is that one commit ID because it's just that hash, right?

There's no history to it whatsoever. It's just that one point in time, it's that one snapshot. So that's, I think, why he calls the branch, the series or sequence of commits. Okay, I could buy into that. But also, I think what I said is still true as well, because that's how you can like the commits leading up to that one, right? So if you were to push up a branch that had five commits in it,

and then I did a git pull and I checked out that branch, and I did a git log on that branch, I would see all five of those commit hashes, right, in the order of the log history that it happened. And I think that's why he's saying it's a sequence of commits because it comes along with the branch. I wonder if I can find that other comment that i was referring to all right well let's move on we won't we will hit the tag thing here in a little bit though i do have that in this particular episode so we'll get to that uh the next thing in this article is a picture of a dumpster that's on fire. He definitely has some opinions about the git command line.

Yeah. For sure. And so what he's talking about here is basically the command set. So the actual commands that you type in, not too much of a fan of basically how it was kind of evolved, but kind of what he calls piling stuff on top of new commands, on top of other commands, and also how it's documented, which is something that I think

at least I've complained about pretty often, just that there's kind of like these weird commands that you can run and there's all these kind of like obscure flags. You're like, if you get like even slightly off the path, things just kind of get a little weird. So I think that's kind of a common sentiment, not too controversial.

But like you said, once things have been out there for a while, it's really difficult to change because it's essentially's essentially a public api at that point right so any changes you make could be breaking scripts or or whatever so it's a it's a problem yeah and i mean he he was definitely colorful and how he explained his hatred of of the gig command line like he wasted probably well i wouldn't wasted. He spent a couple of paragraphs belaboring his point on the dumpster fire. Yeah, I should probably be embarrassed, but because of my not brightness, I will not be embarrassed. Because I actually went back and looked up, he referred to something as being non-orthogonal.

And I'm like, okay, wait a minute. I don't hear that term every day. Let me go back and look at it. What do we mean by that again? And I was like, okay, yep, okay, I get it. You're not the only one. I did the same thing. For that one specifically?

Yeah, and you know the worst part is if you do define non-orthogonal, all the definitions are not orthogonal. And I'm like, you, really? No. No, I went to, okay, okay good i don't feel so bad did because i was like i guess i'm gonna be like the guy who's like you know i didn't put it uh you know because there's like some words in computer science just trip me up every time but uh no there was a i guess i will include a link to the wikipedia article for the

orthogonality computer science definition of it. And then I was like, okay, I reread it like eight times. I'm like, okay, I grokked a 10th of it. Yeah.

That's so funny. All right. So one of the things that this guy says though, that is that I agree with, he said, there's a lot of software out there that you can use that you don't have to have a deep understanding of right and there's probably a lot of software like that i'd even argue that a lot of programming languages people use that way the operating system

there you go like how many people like really dive in to understand their operating system don't know anything about it right but then he goes on to say you can't do that with git and i don't know we'll come back to my thought on this here in a second because i think he's right man i think he's right so you can definitely get into trouble by not knowing but there are definitely people that don't that don't care and they're just like these are the three commands you tell me to run. Okay. I will always do these and I will make sure that I never do anything other than those. And I will never step outside of that box.

And you know, that's fine. That'll get you 80% of the way. Right. And I think that's true. I think what you just said is if you learn the get checkout dash being the get ads and the commits and all that, you can probably make it by for the most

part but what stinks is this is where it really stinks is when they get stuck in in some sort of pickle because they don't understand what's going on then they have to call you right or they call me or they call joe or they call somebody and they interrupt somebody else because because it didn't do exactly what it did the other 20 times that they did it. You know what I mean? Yeah. And that's fine. And like, I think, um, it might've been the other article where they referred to like, you know, no, I think I'm pretty sure it was, it was this article, the main article where he was referring to like going back to your get expert, like when you got into trouble you know and so that that's where my point was like i don't know do you really need to know like all the internals of git like i don't

even think i know i don't i don't i wouldn't even claim to say that i know all the internals of git but i think i'm i'm pretty dangerous with it well yeah i mean i was gonna say like there's some things that are just kind of like tougher than you would think they should be like how do you delete a branch right there's git branch dash d lowercase if it's been merged uh capital d if you want you know if it hasn't been it's got commits that haven't been merged now if it's remote you got to push with the colon so it's just these kind of like these weird things that like you know if people aren't familiar with it then they're not comfortable with it and they just don't delete their branches and someone's got to send an email saying, everybody clean up your branches.

Right. And then they may not even understand it. But I guess that leads into his point of the reason why he said you can't go in to get blind is because he said the commands don't make sense. And this is where he was railing on the commands as they evolved over time is he said, the problem is really what you have to do is you have to think about the state that your repository is in, right? You have to think about what state you want it to be in. And then the problem is there's likely a bunch of different ways to do that transition from one state to another. Um, and we'll actually define repository here in a minute. Um, and what, what his whole point was, and I think I agree with this after having used

get for many years now is he said, if you try and understand the commands without actually understanding what's happening behind the scenes, you'll absolutely get lost. And I believe that to be true because some of the things don't make sense. So my favorite one is this. The opposite of a get push is not a get pull. It sounds like it should be, but it's not. A get fetch is the opposite of a get push. And so just that misunderstanding alone could put you into a bad state right because if you get pulled a branch that you didn't realize you were doing you completely alter the state of your current branch um so that's one um get checkout he said was was uh as was worse than get reset because get reset does three different things depending on the flags that you pass it right so

it's not like you can just think about it being this thing that's going to reset your branch. That's not necessarily the case. So that was his point with being irritated with the command line is because it's not like your standard command verb action type thing to where you expect it to do a certain thing every time, depending on what number of 5,000 flags you can pass to some of these get commands, it's going to do something that you completely don't expect, anticipate, have no idea what you every time, depending on what number of 5,000 flags you can pass to some of these git commands, it's going to do something that you completely don't expect, anticipate, have no idea what you just did. Yeah, I think it's all fair. Like upstream branches, like think of examples of just like kind of things that are just awkward and like if it can really get you in trouble. And yeah, man, if you pull the wrong branch into yours or like have you braced, if you're not

familiar with getting you based off the wrong branch, trying to fix that stuff like that's really painful. Yeah. And for those who aren't aware, like we just threw out a couple like get push, get pull, get fetch, right? Get pull like takes your origin, whatever you're attached to with the origin and tries to merge the changes into whatever your local working tree is. Well, it does it. Let's, let's be more clear. It does two commands in one. It,

it does the get fetch and a get merge operation. And so, you know, the way I interpreted his statement here was like, not necessarily that you're doing the git pull without specifying a remote head or a branch name you know like maybe like i just assumed like you know maybe you are like he because he didn't make a clarification of like what parameters on any of these commands right right so because because even git pull depending on how you use it, can pull different things.

Yeah, it can pull from a local branch, right? Well, I meant there's a difference between Git pull and Git pull origin master. Those two things will do different things. So in the second option of Git pull origin master, you're only pulling down the changes and potentially, you know, and merging them in from a very specific branch. Whereas the get pull will pull whatever the default is, but it'll also pull all the other references down as well.

So other tags and branch names as well. So now your repository will know of those other things. Yeah. So an important thing about what he said right there is if you say Git pull origin master, if Outlog created a branch up there that he wanted to share with me and Jay-Z, if I did a Git pull origin master, when I go to check out that branch, Git checkout shared branch, it won't exist because I didn't pull down those references to that branch at the commits and all that. You'd actually have to do a get pull to get the,

that branch, any tags, anything extra that's up there. So like, yeah, I mean, we haven't even gotten deep into any of this and you can already see how it could be super confusing to somebody that,

that doesn't know how these things actually work behind the scenes. So, and that was, that was actually this guy's point. And I thought it was super valid was he said, the biggest problem is if you don't understand sort of the underlying model, the structure that happens behind the scenes, you don't even know what questions to ask or to Google for to try and get yourself back into a good state, right? Like you did something and all of a sudden you see a bunch of red when you do a get status and you're like, I have no

clue, right? You can Google whatever that red shows up, but you may not even know what happened to get you into that state. So you don't really know where you are. And I think that's fair. If you don't know how to ask how to get back to a good place, then that means so you don't really know where you are and and i think that's fair if you don't know how to ask how to get back to a good place then that means you probably don't understand the system enough to to just really just be dangerous with it it's so funny you remember the first time you installed git on windows and like some of the things you have to answer right off the gate is like how you want to run with sigwin or git bash and you're like oh okay i'm just gonna pick one and like all right now tell us about your line endings like whoa yeah yeah and then

if you want to actually save your password you know back then like it used to be complicated how you'd have to kind of set up your credential manager like hopefully some of that stuff's easier now but like all those things were like you know complicated and you have to get config to set your email and you know now it kind of prompts you so like everything's gotten better but it's just uh it's been a rough user experience for git but it's succeeded against all that because the underlying structure is so good right you know what's so funny about that line anything i remember the first time i saw that i was predominantly a developer on windows so the line in needs you never thought about right like yeah what are you talking about what is crlf versus what what am i gonna do here oh man those those were the worst

so that all that said this was his sort of intro into this thing. And he said what saved him was actually understanding Git. And so we're going to have a link to another. It's not even an article. It's an open source book that is published on GitHub is essentially what this is. And it's called Git from the bottom up. And we're going to talk about this in depth on this podcast without going into very specific commands that they have, like with hash numbers and all that kind of stuff. But we are going to talk down into the weeds so that hopefully you'll get the concept. And really, I think this we haven't had very many episodes like this where I think that we're like, hey, you need to go try this, right? You know, follow along.

I think this would be a good one. If you deal with Git on any frequency at all, we're going to have some links in here that will take you to things like when we start talking about blobs and all that. I highly recommend going up and running the commands that they have there because it will actually burn a map into your brain about how Git is doing things and why things happen like they do. So I guess I'll talk a little bit more. Yeah, sorry. I was just thinking, if I was talking to a beginner, there's like two things you should never do. Never reset at all, ever. You know, I'm joking.

Sometimes you just have to, uh, and also never revert. Well, so the reset I use all the time. Yeah, I do that too. But I mean, that's like, that is literally how you lose stuff. Like when you lose stuff, that's how it happened. Well, depending on the flags and this goes back to his point, right? If you just do a get reset, it sort of unstages your files right yeah if you do a git reset hard you're starting to to lose changes and that's i mean well yeah this is this is so you can accomplish that same thing with the the checkout so if you have if you have already done a git add the of a

file name to undo that git add you can get reset that same file name as joe drinks his vodka while we and the reset doesn't change the file already we've already turned him to alcohol he's already like forget it i'm out so so yeah that i, that's the, that's the rub there though. Right. It's like, you know, you're undoing this, you're unstaging the file in that particular scenario, but then you introduce this like dash dash hard head where you're saying like, Hey, I want to just reset the file back to this specific point in time, which in that specific example, we're saying head,

which is a special variable in get that references, whatever the tip of the branch was. Uh, but you could also do a get checkout minus minus in the file name. And that will also like undo whatever changes you've made to it. Yeah. It's, it's kind of as long as the,

the checkout minus minus, as long as it'll undo the changes that haven't been staged. And this is why it gets so crazy. Oh, by the way, if you ever do accidentally get reset, blow away your changes, hopefully your IDE that you're using snapshot and changes along the way.

A lot of times it will, if you use using IntelliJ, probably even Visual Studio, it might be worth looking in there. That should have been a tip of the week. But so back to Mark real quick, before we get into the get from the bottom up, he doesn't love get like he calls it out explicitly. He's like, yeah, I don't love get, but he did call out that he uses it on purpose. He chooses to use Git because, because it's so effective at what it does and he uses it well because of the learning that he did that we're going to embark upon here. Um, all right. So let's see, what else do we have? Oh, and Ed Outlaw mentioned it just a minute ago.

So the first quote that I put in here that he had was the best advice I have is read Wigley's or Wigley's explanation. Set aside time, go over it carefully and try out his examples. It fixed me is what he said. And then the next one that he meant that outlawed mentioned is it's very hard to permanently lose work. That's really important. If you know how to use get, you probably won't lose anything. If something seems to have gone wrong, don't panic, remain calm and ask an expert. And, and that's the thing, right? Like you don't have to be an expert at it, but at least if you have a base understanding, then you can, you can kind of operate in there without fear. Right. And I think that's important. Yeah. I mean, I remember,

I mean, kind of to his point though, of like learning the, the behind the scenes things, like I remember for me, I don't know what your, your experiences were with it, but like I was coming at it from Mercurial. We were a heavy Mercurial shop at the time, and some colleagues and I were talking about Git, and that was what kind of turned me on to it. It was one of my coworkers, and so I picked up an O'Reilly book and started going at it in depth from there. And that was like a decade or so ago but um i think that that helped like having gone through that kind of detail which is kind of his

point here right it was like you know he's referencing this uh get from the bottom up book and for me it was you know i guess like an o'reilly book or something but every time i look at the o'reilly book i'm like man i swear i don't remember that being the picture. But they don't change the animal. So I'm like, well, I don't know. I definitely did not pick up a book. I probably took one of those online tutorials and said, all right, got it. Moving on. Yeah, I want to know, there was a popular GIF book at the time that didn't have an animal on it. I want to find it now. But I thought it had like a clock or something. It was a popular gift book at the time that didn't have an animal on it. I want to find it now, but I thought it had like a clock or something.

It was like weird. I, I mean, I put the, I put a link, I'll have a link in our resources. We like to the O'Reilly book, but I swear this is not a,

the time that the release date is off. And I'm not sure if they were referring to that's the release date of the second edition. And, but they don't say like what their release date is. The first date is off, and I'm not sure if they were referring to that's the release date of the second edition, but they don't say what the release date is the first edition is. But the second edition date seems like it doesn't line up with when I was reading it. But then, like I said, the animal – but they don't change the animals on the new editions from what I recall. I think Outlaw, he dreamt it up and new get when he woke up the next morning. Apparently like I didn't even know that was a thing,

but yeah. All right. So we are actually going to break here because the very next section that we're going to jump into is actually get from the bottom up because that gets into the technical nitty gritty details. So we're going to break here. All right. With that, we ask, why did the cookie cry?

Crumble. Something cut. It was feeling crummy. Joe was on the right track. Joe was on the right track. Don't get that away from me. All right. Be like Disturbed

Mime and Joko and leave us a review. Like, be like them, right? I mean, maybe not, like, threaten us with, like, a one-star if we don't have you on the show and, like, you're going to, like, ruin the averages, you know? I mean, that might... That's going a little far, but, you know, whatever.

We'll take it. Whatever floats your boat. But, you know, so if you haven't left us a review we would greatly appreciate it uh you can find some helpful links at www.codingblocks.net slash review and with that we head into my favorite portion of the show survey says all right A few episodes back, we asked, does your job include any toil? And your choices were, of course it includes some, but it's a reasonable amount. Or, this topic is opening my eyes to how much toil my job has. Or, I think my job includes too much toil, but my team won't do anything to change it. Or, oh my God, if I removed the toil from my job, I'd have no job left.

It's 190. So to Tuckco's trademark rules of engagement, Jay-Z, you are first. Okay. I'm going to say, of course, it includes some, but it's a reasonable amount. And I'm going to say that we took one. No, no, no. 28%. 28.

Very precise. I was close. I almost messed up. All right. So I'm going slightly more pessimistic on this particular answer set. I want to say this topic is opening my eyes to how much toil my job has. And I want to go with 33%. 33%. All right. Drum roll, please. I was just curious to see if anyone would try to do like mouth drum roll in. Oh my God,

this worked out better than I could have imagined. That was, that was an even better joke than any of the other jokes I've ever told before. Uh, Oh, what else can I get you guys to do while I got you on the line? Um,

Joe wins. Of course. Oh man. Yeah. I knew it. Two course. Oh, man. I knew it. Two-thirds. 66%. Yeah, two-thirds, yeah. Of course it has some.

That's good. That actually makes me happy. That means that people aren't spending their time doing stuff that they hate. It would be weird if you didn't have any. Yeah, if you didn't have any yeah if you didn't have any you're not actually programming yep you know we didn't even have that as a it's an option i guess we were being pessimistic and just assuming that of course you have some amount of toil no no toil wasn't even an option uh all right i mean your your choices literally went from, like, we've got a little bit to, like, we've got it's all toil.

It's Mac style. All right. Well, for this episode, gee, I mean, maybe we'll be a little bit more optimistic this time. We ask. I mean, we're talking about Git, so why not? How do you feel about Git? Your choices are love it, leave it. You better gain way. We ask, I mean, we're talking about Git, so why not? How do you feel about Git? Your choices are love it, leave it, you better gain way, or SVN for life, or I miss Mercurial.

Very nice. But I think it's important, like you beat on your chest when you do the SVN for life, you know. Oh, yeah. For sure. Yeah. Like the Sammy Sosa thing to the club. Wait, that's sports ball. You guys may not get that reference. No, I totally got that reference. Totally.

Did you? No. Yeah, the basketball reference. Oh, God, I give. Somebody's listening to this episode for the first time, And they're like, wait a minute. What? Yeah. We cringe. Well,

all right. Well, while we're cringing, let me tell you this. A man is watching his car with his son. And the son asks, dad, can't you just use a sponge?

I knew it was going there. All right. So get from the going there. Nice. All right. So get from the bottom up. Yeah. Or Jay-Z, you wanted to say something? I was going to say this book, Jay Weekly, we talked about. We'll have a link in the show notes. And it's actually up on github.io.

You can go read this right now. It's formatted really well. It's got some nice diagrams. And it's just really good. It doesn't look like a GitHub pages page to me. Like it looks like a real thing. Yeah. I found the first edition of the,

that book, the O'Reilly one was 2009. So that more lines up with what I was thinking. So that probably, that has to be the book. I just, I swear it wasn't a bat, but still not the same picture though. I, I mean, I thought it wasn't a bat. Still not the same picture, though?

I mean, I thought it wasn't. I definitely know it was an O'Reilly book, but I guess those words just had me so captivated, I don't even remember what the picture looked like. That's it. All right, so getting into Get From the Bottom Up, the first thing we're going to go over is some vocabulary, because I think that's one of the things that a lot of people get confused on and actually frustrated by, because depending on the tutorials you look at, and even maybe some of their documentation, it's not consistent all the time. So they wanted to set out some ground rules here. So I guess,

you know, why don't you guys take some of these? Repository is a collection of commits, each of which is an archive of what the project's working tree looked like at a past date, whether on your machine or someone else's. And as I mentioned before, there are special variables or, yeah, I guess that would be the best way to say it. Well, I mean, we're going to get to this one specifically later. But special keywords or variables, I think variable would be the best way to call it.

Head was where I was going with that. And it identifies the tip of the branch or the commit where the tree started from. Yep. And they actually start. Say again? It starts from the most recent commit. Right. So the last commit that happened on that particular branch. They did call head an alias because it's an alias that points to the latest commit on that branch.

I couldn't think of a good word. Thank you. Where were you like five seconds ago? Well, I didn't want to interrupt your flow there. I'm going to do it. It's okay. And also they said the repository contains a set of branches or tags that allow you to identify commits by a name. So that goes back to that whole sequence of things, right? So if you have a branch that you named my branch, then that is how you get to that set, that string of commits that led to the

current state of that branch. It's interesting. So a repository is a collection of commits. Each one's an archive and it contains a set of branches or tags that allow you to identify. And then you as a user might go to github or gitlab for example and you might clone a repository which is you know like when you say the word clone to me it means you're grabbing a copy of everything right so it's just kind of interesting so i'm just kind of commenting on the the terminology that you use and how kind of awkward and confusing it can be to use words but also it's not like we have better words to really you know kind of using these these for these

concepts like these are i think that's kind of the hard part with gits like it's almost like an alien language that you just have to learn well i think i think after we go through the rest of these definitions and we get into some of the underlying fundamental pieces of it, the Git clone will actually make a little bit more sense. At the end of this episode, I think we'll get to a point where it'll make more sense. All right, good. But this does go back to what I was saying before about the branch and the tag being basically a named reference to a commit ID. So rather than like git checkout commit ID, blah, blah, blah, blah, blah, blah,

which is going to be like some long string, it's going to be some SHA-1 hash. Which you could do, right? You could totally do. That's important to mention. You can totally check it out by commit ID, but instead you can name that thing instead. And it's a lot easier for you and I to reference and say, hey, just get checkout dev. And now you can get the dev and

we can keep iterating on that. And that thing being an alias, it's going to move as you and I update the dev branch in that scenario, whereas that commit ID is never going to move because the commits are immutable. So if you keep get checking, check out some commit ID, you're always checking out the exact same thing. Right. And again, this is I mean, we can kind of go ahead, I guess, skip to the head alias definition if we we wanted to because you can check out the commit id but it would put you into what's referred to as a headless state um you know because you're you're literally just that commit id yeah it's called detached head when you see that um which sucks because if you ever get into that state, that means there's no history.

There's no history, right? Like, you wouldn't... I wouldn't say it that way. What? I mean, the fact that you checked out the commit ID is history. No, it is a snapshot of the state of the branch at that point in time. There is no history there. But that is a point in time. That is history by there. But that is a point in time. That is history by its definition.

It's a snapshot, though. And that's the important part. There might not be additional... You can't commit to that thing and then see more history to it. Nor could you check out the previous commit because there wouldn't be one. It's not linked together there.

So if you check out a tag, right, let's just say that it was commit number 10. If you check out 10, if you were to say like get log on that, you wouldn't see 987654321. They're not there. So there's no, when I say history, there's no sequence of commits that lead up to that in that particular state. You literally have a snapshot of the code at that point in time. Whereas if you checked out the branch that also pointed to that same commit ID 10, right? Let's say that you checked out dev, dev was at 10 and you did a get log,

you would see 10 9 8 7 6 5 4 3 2 1 and you'd be able to see the whole sequence of events that led up to it. Well, this goes back to Mark's definition of it being of the branch being a sequence of a sequence. But but I still want to like I don't want anyone to think that the commit itself isn't history. Like the commit itself is. History, you just can't do anything else from there. Well, that's why they that's why they call it out in the git from the ground up. It is a snapshot of the repository at that point in time. I guess, I don't know, maybe I'm just being weird here.

Because to me, every commit is a point of history. So that's why I'm trying to be careful with the wording here because as we get later on into here, when we start talking about the ref log, right, that's all history and you could go back to any one of those commits, which is a moment in history. It's a moment in time. You might be limited

in your options, like what you're saying, in terms of Git log from that point and seeing everything else that's from there or being able to commit more into it. I understand where you're going with that.

I think the biggest thing to take away from it is there's no timeline, right? If you check out a commit, it's that. That's all you have. If you check out a tag, it's just that thing. You can't look back across the timeline and see what led up to it if you're on that commit.

What might be helpful here? We're talking about commit. Let's define commit. A commit is a snapshot of your working tree at some point in time. So that wording right there, some point in time, goes along with what I was saying. It is kind of history. It's at some point in time, right? It's a historical marker, right? I think so. If I, let me, let me pull this out into, I think the difference is that log option is what you're, where you're going. Yeah. The analogy that I can think of is this, right? Like if you have a video,

a video is just a sequence of pictures, right? More or less with sound, but let's just take sound out of the equation. And the commit would be like one still of that video. It's one still in that video with no linkage to the shot before it or after it, right? Like that, when we're talking about a git commit and if you check that out or you check out a tag, you were checking

out that picture. You cannot look before or after it. But that picture still represents a moment of history. It's a moment of history. That's the distinction I was trying to make. It's a moment in time. This is where it gets hard, right?

If you're talking about history, then it implies that there's things leading up to it. Yeah, of course there were things that led up to getting that snapshot. If I show you a picture of the delivery of my son, you can infer that things happened to bring him there into the world. A stork. A stork.

Well, they do say that a commit is the state of head at the time the commit was made. So it does imply that it requires the rest of that history in order for it to make sense because it's ultimately a diff on the state before. So you can't really have just a commit by itself. It kind of implies it's got the diff on the state before. So you can't really have a, just a commit by itself. You know, it kind of implies it's got the, the, the chain, the history along with it.

It's, it's a very bizarre thing, but we're going to go further into this. So let's, let's move on past this. The next thing that, because we're going to have to come back around to it. I don't even think we're going to get to it in this particular episode in

terms of what it'll mean when we get even further into this. The next thing that they define is the index. So here's what's really interesting about Git. And I'd say probably one of the things that I like the most about Git is Git does not commit the changes from your working tree into the repository. So instead of committing those things straight into the repository, like you might've done with a subversion or something like that back in the day, the changes are registered in the index that is also referred to as the staging area before you actually commit, quote unquote, those changes into the repository. So what we were saying earlier about get reset and what it could

do, right? Let's say that you made some changes to a file right now. You just made change to a file. Nothing's happened. If you say get add that file, what it does is it stages that file as something that get is going to know about that you're going to want to commit at some point. But when you do a get add, it just adds it to the index of files that Git is tracking now. You have not actually submitted any changes to that file into the repository. It is just sitting there waiting for you to do it. And that's where if you Git reset it, where you staged it and you said, Hey, I have my new file in here that I care about. If you didn't get reset, it just takes it out of the index.

Nothing ever changed in the repository in that particular setup. That's asterisk, right? Which part? The, the change into the, to the repository. Cause I think later he does go into like technically when you stage it

there is it is being added into the repository in a special format that's why you're able to like get checkout minus minus changes on a file after you've staged it and you're only undoing the changes since you last staged it. But so it is, it does technically still know of the new changes that you staged. Right. So like, that's where I have like a lot of things in life.

It's complicated. Right. But, but I did want to go back. So I was curious about something because I'm like, wait a minute, is that true? And I want to correct it because if you check out, if you get check out a commit ID, you can see the log history. But if you get check out a tag, you cannot.

I didn't try a tag. But I'll try a tag in the background. I don't remember. So my guess is if you get check out a commit, my guess is it's probably finding the alias or whatever branch has that as the tip would be my guess. But I don't know. I mean, no, you're just checking out the specific.

Okay. Here's, here's the one thing. And, and they kind of cover this here too. If you were to think of everything as a commit and then build on it from there, then what you just said wouldn't have made sense, right? Because a branch is nothing more than a commit, right?

And here in this definition from the bottom up, it says a branch is just a name for a commit. And we talked more about commits already. Also called a reference. But literally, there's nothing. But not everything's a commit. And that's where I was getting ready to go. You can't think of everything as a commit because actually the most basic building block is the blob yeah they are which we'll get into in a little bit so and that gets even more crazy because there are types right

there's blob tree other stuff and and we'll get into that but that's why commits like a level above it is sort of what stores the metadata about the actions that did happen at the time and it's pretty amazing you can work with something for like 10 plus years and still like have arguments about it. Yeah, exactly. Like, uh, so, you know, it's interesting. And I'm wondering, it's like, is it just hard? Is it confusing?

Is it? Well, I think that's Mark's point. Yeah. Yeah. Yeah, it is. And totally, I mean, that, that's when we started looking at this, that's what kind of surprised me is how much I didn't actually know about what it was doing behind the scenes. Right. And so let's get into that, because I think I think with Outlaw, he and I going back on the history thing, we're both saying the same thing. Um, it's the terminology that, that is tripping me up and probably, probably just the way that we're communicating about it is, is the hard part, especially cause he knows get way better than I do as far as the commands and, and how to do things. Cause

he has done crazy stuff with get that most people probably haven't done. Um, so let's knock out the rest of the vocabulary and get into some of the fundamentals of what it's doing behind the scenes, because that will actually paint a picture of what's happening on your hard disk. I think working tree. Yeah. So working tree is the next one. So and that's any directory on your system that is associated with a repository. And the shorthand, you can think of like anything as a git folder so when you clone something uh what your working tree is that local folder on your computer that is associated with that git repository that you're actually doing your local work in and that git

folder it's talking about is dot git yes and chances are depending on which os you're on that's hidden so if you're on windows you'll have to show hidden which OS you're on, that's hidden. So if you're on Windows, you'll have to show hidden files. If you're on Mac, you would have to do the same thing. But if you did like an LS-AH or something, then it should show it up in your file system, right, from the terminal. Yep. And branch. Wait, wait, wait. The commit wouldn't do the state of the head one first.

Okay, yeah. This is kind of a sub-blender. So commit, we talked about being a snapshot of your working tree at some point in time. And it's not just the one commit, but also the commits that load up to it. And the state of head at the time that your commit is made

becomes that commit's parent. This is what creates the notion of a revision history so as you make a commit the new commit becomes head is basically what they're saying head moves as you go along right and that's always does some terminology that's always confused me there's like been some sort of um you know merge or something it's like which one's the parent i'm like well i'm out of here let me try this from a different angle right uh so branch uh name for commit uh difference there being that unlike the head which kind of travels as an alias to it to whatever is it is um so it stores the history of commits um and and this

is where they talk about the lineage it being the branch of development so when you have a branch right you check out that branch well god i mean i guess if we go back if you were to say when you created the branch whatever you branched it off, we said was the starting point of that branch, right? So the head of wherever you checked it out from becomes the beginning of that lineage of that branch, right? So now any commits you make to that branch, it's just history stacked on top of that original checkout. Yeah, I just got tripped up because I'm thinking a branch is a name for a commit, which is not different from head, but my branch locally can have a different head from my remote server

because I haven't pulled lately, or maybe I've got some stuff checked in. So the head of my branch is the head of the remote. So it's kind of confusing to have this term that kind of refers to to or to say that it refers to any sort of commit. So it's just kind of interesting. It's your working trees branch, right? And that's the key. If you're looking at the origin or some remote, you're right. Its head could be totally different because it has different commits than what you've done to yours locally, but your working tree branch is whatever your latest commit is

on that particular sequence you checked out. Yeah, it's kind of weird because a branch can mean different things to different people at different times. So I can say, hey, what's your branch got? What's your latest commit in your branch? You can tell me and I can tell you the latest commit in my branch, and they can be different. So the branch is just kind of like a handy way of referring to this like lineage uh and the heads

for that lineage can be in different spots based on who we are what we're doing and what kind of mess we've gotten ourselves into yep it's kind of interesting um tag uh another uh label similar to branch and head uh the difference here is a tag is a name for a commit that stays. So if I tell you, Hey, check out this tag, it's always going to be the same. Uh,

I said, I'll, he said, maybe you can change tags. Is that true? Kinda. So what you can do is if, if you tagged something, let's say like a common workflow is you want to tag your version that you put out there, right, into the world. And you're like,

if I ever want to go back to 1.2.3, then I've tagged that version, I've annotated it, I can go back and find that thing and I can check that tag out if we ever needed to. Right. And then Alan comes along and he's like, Oh, I got like a bug fix that I just merged in. And this is the version that's supposed to be one,

two, three. And you're like, Oh man, I tagged the wrong thing. Well, kind of technically like to the rest of the world, it's going to look like you changed the tag,

but behind the scenes, what you're going to do is delete the other tag, retag the new commit. And you know, so correct. You didn't like really, you know, uh,

uh, change the tag. But as far as like everyone else is going to care, you did because it's a named reference to the commit. And the commit has changed. And you changed what you're pointing that name to. So as far as all your teammates are concerned, you made magic happen and you updated a tag that isn't supposed to be able to be done. But really, you didn't. You just deleted the old one and recreated one with the same

tag name. You should probably not do that. You have the ability to do it, but in practice, it'd be kind of weird if you asked someone, like, hey, what code's up on the server? And you tell them the tag name, and they're like, ooh, was the tag name from before or after

Outlaw pushed out Fixin? It's just kind of a nasty thing. Yeah, that's almost the equivalent of changing history on an origin. Almost. Sort of. Maybe. Depending. Because the problem that you could run into, based off what you just said, though, is

if you did a git pull yesterday when it was the old one and I did a git pull today when it was the new one one and we both checked out that tag we're checking out two different references right and that's that's the danger of it is the history ish sort of even though it's not really history changed on it the i mean the uis around it make it super easy like you know for in like azure devops or a github like it's it's not hard right but it's really just it's a timing

thing if somebody didn't pull um the most recent changes before checking out the thing and that's that's where things get dangerous but that's where things get really dangerous would get in general is if if if something changes that you don't expect to change it can be it can be nasty yeah you might just want like accidentally tagging the wrong branch and then expect to change it can be it can be nasty yeah you might just want like accidentally tagging the wrong branch and then trying to fix it the next day and like oh i can imagine all sorts of terrible things don't make manual changes start left yeah right yeah so more manual tags in the year 2022 the next one they have is master so So it used to be, and I say typically, probably not as much now. The mainline branch where development was done in the repository was called the master branch.

I think a lot of companies and development teams have changed that to dev or something else, right? Just to get away from the term master or main right yeah i think that when we did um minimum cd i think that that one advocated for trunk as being the the main branch name but i've seen uh like azure devops i believe was um going down the um main path as the main trunk branch, main branch, whatever. But yeah, it's definitely, uh, you know, the, I would say like the industry as a whole, we're moving away from, uh, you know, the default name. Yeah. And here's the cool part. It really doesn't matter, right? You can name it whatever you want because the branch has no special meaning whatsoever. It's the same as any other branch that you have and get. So, um, yeah, that's basically it on that. Um, head, this lets the repository identify what's

currently checked out that like, like outlaw said, that's the tip of your current branch. That is the latest commit that has been put in there. Um this is where they called head an alias. If you check out a branch, head now symbolically points to that branch. So that's what you're on. When you say head, you're on the latest commit of whatever branch you've checked out.

And then we did that. All right. And then they point out the typical flow of, of what happens in get, and this is general. And this is where going back to what outlaw said at the beginning is if you kind of learn the commands to do this simple flow, assuming nothing crazy happens,

you'll probably be okay. 90% of the time. So the first one is you're going to create a repository. You're going to do your work in your working tree. Remember that's just the directory that you're working in that's attached to a repository. Um, once you achieved a good stopping point and they said it could be the end of the day, it could be once your code compiles, it could be whatever. Then you add your changes to the index, which is a get ad a Git add that doesn't actually commit anything to the

repository yet. Once your changes are in the state you want them to be, once they're in the repository, that's when you commit those changes that you already added to the index. And that'd be your Git commit. And we talked about this on our Git episode a long time ago, like episode 90. Good Lord, man. You looked it up before this didn't you no i just knew that one off the top of my head it comes that one comes up so much it's unfair that one comes up a lot bad oh i think we even said back then like typically if you're committing something that you're going to be pushing up it should be working right i know we talked at the time that you know some people commit things at the end of the day

or they commit things whenever. And Jay-Z commits when he's changing rooms. He did say that. Yeah, I still do. He was like, oh, I'm going to leave the office area and I'm going to go downstairs and watch TV. So I'm going to commit. That's crazy talk.

Because God forbid, if he were to like trip on the way down, actually hit that delete key. Yeah, you don't know what could happen. Yeah, right. But yeah, it was episode 90, comparing Git workflows. And I'll have a link to that

in the show notes as well. Cool. Okay, so I do want to like just close the loop on one thing though i i in the background did test and you if you do the get tag if you do check out the tag you can also get log it oh and it'll show you all the commits it'll show you the history leading up to it yeah i thought that sounded odd i never i couldn't remember like having done that but i was like okay let me go create a repo and then a bunch of commits and files and stuff and see what happens but yeah you can totally which makes sense right because like you could obviously see like what led up to that point in time it would never be just that that one thing you can always see like what, what got you there.

Then why I'll have to do some, some reading and some research on my own and see if I can clear up what they mean about it. What's the question? Well, I mean, it doesn't, it doesn't follow with what they're saying about the sequence of commits,

right? And that's, that's what I don't get. Like when they say that get from the bottom, from the bottom up article or Mark's comment. Cause like I said, like when Mark's comment about the branch thing, remember like I questioned that immediately.

Yeah. I think Mark is the one who said it, but then... Like, if you have a detached head when you check out a get tag, you're in a detached head. That means head's not actually pointing to a commit. Is that what that is? Like, I don't know.

Like, it's sort of unclear to me how a tag is really different than a branch if you can still if head traits everything if head symbolic okay go back to the definition from the bottom up and by the way i'm no way trying to call out like mark's you know definition for the branch thing it was just like i'm not saying that sequence of commits wasn't a good way to think of the branches but uh go back to to the get from the bottom up and their definition of head, right? Head symbolically refers to that branch. But if you're not on a branch, then what could head symbolically refer to? So head, okay, so when you're checking out a tag then, you're actually checking out that commit and all the sequences of commits that led up to it. However, there is no such thing as head because head is not pointing to anything

at that point in time. Yeah. You're not in a branch. And so when you're in a branch head is just the tip of the branch that you're in. But if you check out a commit, you're not in a branch. So there is no head and it doesn't want you to be able to do anything, right? Because the whole point is head moves with whatever the commits are head. like you said earlier, alias is a great way to think of that, right? Like it's going to move as your commits move. As you add commits, head is going to like move. And if you're not in a branch, you should not be able to add additional commits. Like if you ever find yourself on a tag and you need to make changes, what you have to do is you have to check out to a new branch, then make commits, commit them, do whatever.

And we called that out as being like one of the workflow problems in episode 90, depending on like, you know, if I recall correctly, we called that out as like if you do this workflow where you're tagging a commit as like, hey, this was version one, one dot two dot three. And now you want to like do something to it. Then it gets weird because yeah, you can go tech, check out that branch. I mean, I'm sorry.

You can go check out that tag, you know, V one dot two dot three if you need to. But if you wanted to make any changes or let me rephrase that, if you want to persist any changes, you have to create a new branch and then commit your changes to that branch. Right. And then you can't check it. You can't merge it back into the tag so you now have this weird state of like well where am i going to merge this back into right in order to you know keep this thing around forever so you know yeah the the workflow one was really good if you haven't already listened to it like i said there'll be a link in the show notes for episode 90 because it goes into i mean right now we're getting into like the nuts

and bolts of like the blob storage kind of stuff that you know like the file system management that gets doing behind the scenes for you to manage stuff but um the comparing get workflows we go into like more of the practical usages of get like, Hey, you know, depending on, I need to maintain multiple concurrent versions and like, Hey, you know, here's some things to consider. Or maybe you're in like a situation where like, you know, web development is kind of like this easy anomaly where it's like, you can just always more often than not just roll forward. Right. Oh, there's a bug. We don't need to roll back. We'll just push out a new fix and done. But, uh, like when you have to support multiple concurrent versions, especially like on-prem products or, um, you know, maybe you have like different, uh, mobile developments or

app developments that you don't have, you know, easy control over or, or, you know, cause you're supporting like multiple versions of that operating system, then, uh, you know, easy control over or, or, you know, cause you're supporting like multiple versions of that operating system, then you know, it, it, the, those workflows become more important. Yeah. I'd imagine if you're doing something like an Android app to where, you know, there's tons of versions of Android out there at any given time, whereas unlike iOS where they try and force you to upgrade over time, right.

You're probably going to be handling multiple concurrent versions. And we definitely talked about some workflows that work better for you if you live in that world. I mean, just look at some of the package development under Linux, though, for example, too. I mean, it's just as hairy with like all the different versions that you might have to have to have support for. And you can go see it, you know, like even in Docker, for example, right? Like you can go see all the different versions of a Docker image of support. So the idea is like, if you had to think about your product supporting these things because of like

OS being a common example, then, you know, that's where some of those workflows come into play here. But, you know, like one of the interesting things that I didn't realize as part of, as part of this, you know, this reading, we'll get more into it, uh, in, in coming episodes, but, um, like behind the scenes, we've talked about like indexing, uh, techniques and strategies, you know, for like how, uh, like Kafka might like keep files organized on a desk or, or like when we were going over, um, the designing data intensive applications, right. And all the different, um, tricks that you might go through with like, you know,

different B trees or whatever to, to keep things, uh, organized. Well, those commit IDs, like it actually breaks those things up and like, that will be, you know, uh, organized. Well, those commit IDs, like it actually breaks those things up and like, that will be, you know, sub directories. So like the first two digits of it might be one sub directory. And then underneath, uh, like this is all hidden underneath your, your dot get directory. Right. But then, uh, you know, the remainder of it might be another, um, a file or directory or whatever, depending on the situation. It was kind of cool to me. I never bothered to think about it.

I saw it there, but I just never cared to really get into the details of, hey, why is he doing that? But now I'm like, oh, I guess it's some kind of optimization they're trying to do to, hey, I don't want to have all of these files broken apart. You know, I don't want to, you know, maybe it was like a Windows limitation, a number of file limitations on disk or a Linux or Mac or whatever operating system might have had some limitation of the number of files in a given directory. And so, you know, they started doing these little tricks to break it apart. Or maybe it was just a speed optimization thing. I don't know. Either way, I thought it was neat. Yeah, I did too. I had no idea that stuff lived there. And we will get into a lot of those nuts

and bolts on the next episode. Yeah. So like I said, we're going to have plenty of resources we like or plenty of links, including the article that got us here from, how did you pronounce his last name again? Mark Dus? Hold on, sounds right. Dominus, I think. Okay, that sounds better. Dominus, and then the article, the book from Jeff, or no, I'm sorry, Jeff. Boy, I can't even read. John Wigley and Alan will correct me and tell me how I'm wrong there, Jeff. Boy, I can't even read. John Wigley?

And Alan will correct me and tell me how I'm wrong there, but it's called Git from the bottom up. Well, it could be. I think it was a W-E-I or W-I-E? I-E. I-E. Then it's probably, if it's German, it's Wigley. Dang it. The second letter of the I-E is what the sound is in German.

All right, so everybody on the other side of the pond is what the sound is all right so everybody on the other side of the pond is like i'm gonna strangle outlaw but but it may not be german so i might be saying it totally wrong that's okay yeah i give i give you if i have ever bastardized your name i give you full permission to bastardize mine uh you know yeah feel free. I can be Mackle. Uh, you'd be like, yeah, and I'll,

and I'll answer it. And I'll be like, yep, that's me. Mackle. I kind of like that. Uh, I do too.

Oh God. I see that one sticking. Boy, I should, uh, should have thought that one through. Okay. Well,

uh, with that, we head into Alan's favorite portion of the show. It's the tip of the week. All right. So yeah yeah in my first wait you're going first oh he is first i scrolled down too far that's my bad that's right that's right what's up i'm still here i'm awake uh yeah so uh i uh i have crappy tip though you

should have gone first sorry it's not a crappy tip it's an amazing tip actually have you all ever heard of celeste the video game celeste no okay uh it's amazing it's a little 2d game where you like kind of jump uh and you are climbing your way up the mountain it's got a little storyline uh that's surprisingly well done and it is nails tough like nintendo tough beat you in the face except that there's infinite lives and it's very forgiving so this is kind of thing where like you have to be insanely good for like 10 seconds at a time and failing just puts you back like 10 seconds so it's this kind of interesting thing where it's like really hard but you feel really good so it's like yeah you're gonna you're gonna die like 10 times in a row and then you're gonna do it and you're gonna feel amazing and then you're gonna go on the next screen

and it's really well done like every everything about this is well done and it was primarily primarily developed by one person i believe i double check that here uh it's on all platforms it's uh it's kind of a cheaper game i think it's probably like 20 bucks if you get it you know a full price somewhere steam itch.io nintendo playstation 4 xbox one epic yeah yep and it's uh from 2018 uh let's see here yeah there were two, two programmers, and a couple of extra artists. But it was a very small team, like an independent team. But I just am constantly amazed at how well it's done. If you look at it, like just a still shot of it, it looks kind of like an old-school Nintendo game.

It doesn't really look like much. But when you play it, it's just really fast and really precise. And it tells a really surprisingly interesting story. And just the whole way it plays out, it's just a really cool experience overall. Obviously, it's very much a video game, and it's like a video game video game. No doubt about it. But there's something special about it that is worth checking out. So if you've been sleeping on Celeste, if you've been thinking about it,

or you just like Nintendo stuff, or you like something that's challenging but rewarding then i would check out celeste oh and i should mention too uh there's supposed to be a ton of of accessibility settings so if you don't want to get your face beaten in like a thousand times like i do then uh you can change it so that spikes don't hurt you and you get infinite jumps and you can slow it down and things like that so if you just want to kind of play the game for the story then you you can do that too. But, uh, it's, um,

just really great. And so I highly recommend Celeste. Well, since you thought, I want to interject real quick here, Alan, since he, he didn't like his,

his tip of the week, or he said it was going to be a crap one, which I thought was actually a pretty good one. I don't know why you're so hard on yourself. Pretty good. Decent. I was giving him better than decent, but I'll tell you this though,

Joe, cause like a little like from me to you advice so uh you know because you got some time right before next valentine's day but you know i decided to get my wife some beads uh for an abacus and you know it's the little things that count so that one might be getting me shot i don't know. Dude, that was an excellent one. Who had that one? That was Dad Joke. Yeah.

I've been using the Dad Joke API for... It's coming out with some gold. You got to go back to that favorite API episode. All right. So it didn't sound like it was Flappy Bird's frustrating, right? So it's definitely... I it was Flappy Bird's frustrating, right? So it's definitely. I wouldn't say frustrating. Okay.

It's really like you will die. I've definitely died over a thousand times, but it never sets you back that far. And so it's, you know, you don't really get, at least everyone I've talked to, I don't get frustrated. I don't get mad. I just try and do a little better. And it's one of those things where like, I'm like, I'm just going screen and i'm gonna go to bed right and then i do it i'm like yeah that feels so amazing well let me just try this one so i can see what it's like and then you know you start getting it yeah and just keep going keep an hour later do you remember yeah it's it's totally

adult friendly because it's you play in basically 30 seconds at a time, you know, like 10, 15 seconds of activity. Do you remember life before save points? And like you're playing Mario, you know, and you're trying to save the queen or the princess rather, but you're like, oh, I got to go to dinner. And so you just pause the game. Like infinite pause was your save point, right? You might even do that overnight. Oh, but if there was a power outage or mom didn't know

and turned it off. Yeah. I was on the third level. That's amazing. Yeah. Alright, so I got a handful this time. Keeping with Alan's consistent. If we did an episode a week, then I wouldn't have to do two or three a week,

right. Or episode or whatever. I got to make this the tip of the week here. So even if we did a tip one every week, you'd still have like two or three. Yeah. There's, there's so many good ones.

All right. So I got some golden here. One is from straight up pain that I've been experiencing. So we've talked about the, the dependency hell that you can get into in.NET. We've talked about it in various languages. Well, I've now experienced it in Java, and I don't like it there either. Well, is this like a Dr. Seuss book? I've experienced pain in C Sharp.

I've experienced pain in Java. I do not like my dependencies conflicting. I do not like them, Sam, I am. pain in Java. I do not like my dependencies conflicting. I do not like them, Sam. I am. I promise you. So one of the things I ran into is, you know, I've brought up a tip in a past episode of where you could use MVN dependency tree, right? And it would show you all the dependencies that were happening everywhere in your application,

which is nice, but it doesn't show you where things conflict. Sure, you could probably scroll through a million lines of that output and try and find it, but it's not going to help you much. There is, so I've got a link here to the article because I want to at least give them credit for putting this useful thing together. There is a plugin for Maven. At least there might be one for Gradle. I don't know, but if you're a Maven, there's one called the Maven enforcer plugin. And what this thing will do is you can actually run the Maven goal of Enforcer and it will call out anything that has conflicting version dependencies amongst your transient dependencies, which is fantastic. It still hasn't solved my problem because even though I found a million of them, I still haven't like, I got all the compiles working, but now I get runtime errors.

So it's like, I still can't win. So I'll probably end up finding another tool that'll help me. There'll be on the next episode. Um, but this will at least help you step through and see, you know, what,

what is, and Oh, by the way, the reason why it's so good is it will actually show you the tree of what was calling the things that got down to that dependency. It was conflicting. So you have a smirk on your face outlaw. I was thinking of like, and I swear there might still be one. But when you were talking about using Maven to do the enforcer goal, like it made me think of like a song and I'm like,

Oh man, I think there's a movie that had like this song. But then as I was like trying to find, figure out which movie it was, I remembered the one that was, I was thinking of was berserker. Oh, I haven't heard of that one.

I know the song informer. That one too. I thought of that one too. And I was like, no, no, no, that's not it.

Yeah. All right. So that one, again, it's, it's hyper useful. Um, especially if you have a ton of dependencies and jars that have transient dependencies, like there's so many, I mean, I spent hours today manually removing and changing things and I'm still not there. So at any rate, um, toil is what I like to call that. Um, here's an amazing tip for those of you who offend people like I do by typing into Slack and hitting the enter button and ding, ding, ding,

like, you know, outlaws over there, like, dude, will you please stop hitting the enter button? Um, there is a setting in Slack in the advanced preferences to where you

can actually tell it that the enter key will do a new line and not send the message. So you can set this preference up. And then if you actually want to send the message on Windows, you'll hit control enter on Mac, you'll hit command enter. And that means that you can type all the paragraphs you want without irritating people nonstop. And, um, so again, that's a shout out to Jim Hummel sign on, on sharing that in our tips and tricks and, or tips and whatever it is in Slack. And if you haven't joined the Slack community, go to coding blocks, that slash Slack and go ahead and get in there. Cause it's awesome. And Sean, that wasn't nice that you called me out for that. So that was one. All right. And then the last thing I want to do, and it was Outlaw who just said something that triggered this, and we may have said this in the past and I can't remember,

and I'm going to try and find a link to the Docker downloads page. We talk about Kubernetes a lot on this podcast because we love it and we use it a lot. There is a very frustrating thing about Docker desktop with Kubernetes. So one of the things that they did a while back that was kind of awesome is they bundled Kubernetes in with Docker desktop. You could just click a checkbox and you'd be like, Hey, I want to turn Kubernetes on so I can do Kubernetes development with Docker desktop. that sounds fantastic until if you're a good citizen like i try to be and upgrade my docker's desktop when it tells me that there's an update out there for it the problem is it also versions your kubernetes version with the version of docker desktop you're doing hate that they tied those two together it's so ridiculous and And I'll give you the reason why it's very ridiculous

is because a lot of times Docker desktop will have newer versions of Kubernetes out there that are available in Google Kubernetes engine or in AWS's Kubernetes engine. I don't even know what theirs is or Azure's Kubernetes engine. So basically, if you want the latest Docker features, which really, let's be honest, are there for container features, you are completely tied to whatever version of Kubernetes they're doing. So it's really frustrating. there is a page on Docker's site to where you can download a specific version of Docker if you need to run a specific version of Kubernetes. They'll typically have it in the release notes, what version of Kubernetes is shipping with that version of Docker desktop. So that's one tip. The other tip to follow on the heels of that is, if you don't want to deal with that and you want to run the latest version of

Docker desktop, and you also want to be able to target a specific version of Kubernetes and not have it tied to Docker desktop, you can run mini cube. And when you start up mini cube, you can tell it the version of Kubernetes that you want it to run. So, um, I'll have links in the show notes for those things. I've got to dig up the one for the docker download thing but um hopefully that'll help somebody out there they they're not the same and and it was hyper confusing to me back in the day because you'd look up kubernetes um tutorials and some things would tell you minikubes other things would tell you docker desktop but i didn't know they were different um so yeah, maybe this will help somebody.

All right. So, okay. So for first, my, my, I got a couple here, but the first one that I'm going to say is kind of a silly goof on my part, but you know, Hey, we were, we were talking about this recently in Slack about like, Hey, you know what? You can totally save a life if you wanted to help somebody out. You can go donate blood, donate platelets, plasma, or bone marrow, like whatever you want to do. And this is where the silly goof on my part is, is because I just assumed, like I knew that they have blood drives. And like you might see the bus at your local gym or whatever around you. part is, is because I just assumed, like I knew that they have blood drives, like, you know, and like, you might see the bus at your local gym or whatever, you know, around you, you know, I knew that was a thing that would, you know, vary depending on time and location as to where it would be. Obviously. I also just assumed like, Hey, it's Tuesday and I want to go get blood. And I got 30 minutes. I could just go to like my local, you know, hospital or doctor or whatever

and be like, yep. You know, why don't you you take like two or three pints, whatever you need. Get the job done. But at least for my area, know, that's reasonable with my work schedule and whatnot, because the windows of time are like super short. Like, you know, they're done by like two o'clock or something. And so, yeah, it's been, it's been difficult to find one in my area. But, so at any rate, I'm going to have a link to the Red Cross where you can find a blood drive near you. So if you wanted to donate blood, platelets or plasma, Red Cross will happily do it. And another benefit to doing that is if you wanted to know your blood type, they will tell you your blood type, too. And so then like, um, I know in iOS and I'm sure Android has it too, but you like, you can

update your personal, uh, details to include all your vitals, especially in case of an emergency situation. And then like an EMT operator, uh, can, you know, use, use your phone to pull up your vitals. And one of the things could be your blood type, which in a life or death situation, you might be saving your own just by knowing your blood type. So there's that. But I'm also going to have a link to bethematch.org. And if you wanted to donate blood marrow, that is a resource that you can do. And here's another goof on my part. I just assumed that I've donated blood and platelets before, uh, plenty of times I've never done a plasma or bone marrow, but I just assumed that the bone marrow would be like, yeah, we'll just take a bag of it. You know, we'll just put it in this bag and keep it in the freezer.

And when we need it, we'll just pull it out of the freezer and give it to somebody. Right? Nope. It's it's bone marrow is more like it's it's almost akin to like an organ. Like they have to know like, oh, we have a need for it right now on this person. And you are a match. Are you available to come in and and do the donation right now? And so be the match will basically is like a registry like you can sign up to say like, Hey, I would like to do this. And, um, they will,

they, you know, they'll keep your contact information and they'll contact you, uh, when you're needed, you know, uh, based on they have a match and a need,

but also no. And here's another part of the goof on my part for, uh, the bone as it relates specifically to the bone marrow part, there's an age limitation on that, which I totally didn't know. I totally would not, it makes complete sense, you know, after reading about it, cause they're like, well, we need to, the stem cells for the younger, the younger, a younger person's stem cells are going to be, you know, better for this case. And so,

you know, uh, older, you know, then it's like, thank you for, for wanting to be a volunteer, but, uh, you know, whatever. So, you know, you can try it and find out, uh, you know, if, if you qualify or not, obviously me being 21, uh, I definitely qualify. Um, so at any rate, I'm going to have some links to that. So, you know, you could totally be somebody's hero in your area and you might not even know, but you could definitely put a smile on their face. So then kind of similar to, you know, the bells that Alan was dinging with Slack, if you want to turn off all the stupid bells in WSL, I'll have a link to a Stack Overflow answer that goes over

the annoying number of places that you have to make changes in order to remove the bells. But, uh, this answer goes over the bells for bash, uh, them and less. So at least covers three, which for me, you know, you get into, um, WSL and you're like relying on, if you rely heavily on tab completion, like I do. Oh my things can just get so annoying. So yeah.

Uh, turn that stuff off, save yourself. Um, so yeah, we'll have, we'll have a link to that. So,

uh, with that, subscribe to us on iTunes, Spotify, Stitcher, wherever you'd like to find your podcasts. And, uh, you know, as us on iTunes, Spotify, Stitcher, wherever you like to find your podcasts. And as I said earlier, if you haven't left us a review, we would greatly appreciate it if you would take the time to leave us a review. It really does mean a lot to us, puts a smile on our face.

And you can find some helpful links at www.codingblocks.net slash review. Yep. And while you're up there at the site, check out our show notes. Like I said, we keep pretty copious show notes, examples, discussions,

more, and send your feedback, questions, questions, and rants to our Slack community at codingblocks.net slash Slack. Yeah. And if you're not feeling like joining Slack just yet, why don't you throw us a follow on Twitter,

hang out, see what we post. And you can do that, or you can do both at CodingBox or go to CodingBox.net where you can actually do both via all the social dillies at the top of the page.