Coding Blocks - Git from the Bottom Up – Commits

Episode Date: August 29, 2022

We are committed to continuing our deep dive into Git from the Bottom Up by John Wiegley, while Allen puts too much thought into onions, Michael still doesn't understand proper nouns, and Joe is out hat shopping.

You're listening to Coding Box, episode 192. Eight more to go, we get 200. I think that's like a, do we get like a free sandwich or something? Like, you know, 10th one, it's free, something free, I don't know. Subscribe to us on iTunes, Spotify, Stitcher, wherever you like to find your podcasts. I hope we're there. Man, if we're not by now, then I guess you should probably use iTunes, Spotify, or Stitcher then. What is this random thing that you're using? now, then I guess you should probably use iTunes, Spotify, or Stitcher then. Right.

What is this random thing that you're using? Yeah, no doubt. Although somebody will reach out and be like, I didn't find you on Azeguas. And they'll be like, okay. All right. Is that a thing? It is now. Yes.

All right. So you can visit us at www.codingblocks.net where you can find all our show notes, examples, discussions, and more. And you can send your feedback, questions, and rants to comments at codingblocks.net where you can find all 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 at a coding blocks. And if we've got a website, a coding box that we can go there and we got links to other things. So you can check that out.

And when you're done, you should know that I'm Joe Zach and I'm Michael outlaw. And I am Alan Underwood. We're talking about get, so get get excited are we because i was gonna ask you guys where do hamburgers go to dance but yeah we can talk about get instead well in that line now i want to know about these burgers me too the meatball. Oh, that's good. I like it. All right. So,

uh, we want to give a thanks for the newest reviews. So from Alex, uh, Woodhead, we have a new review. So thank you very much for that. And I haven't read that one.

I need to, you didn't. No, it didn't. I've, it was really good because it was a three plus star review all right we love those oh yeah it was he says as requested here's a three plus star review oh thank you alex that's excellent and and super thanks because it was a five star but you know technically he was

accurate that it was a three plus star review so yeah that's amazing all right well hey uh i'm doing ludum dare uh which we talked about uh yeah ludum dare it doesn't look it doesn't look it's uh the name in the notes does not look like it's pronounced uh it looks like ludum dare but do you guys remember talking about this no all right All right. I think so. So it's a game jam. It may be the first game jam. I forget. It's over 20 years old. They've been doing it for 20 years.

They're on number 51 now coming up in the end of September, September 30th to be specific. And going on to October 3rd. And I took a day off work and I'm going to do it. You took a day off work for a while. This is serious. Now we're getting somewhere. Doing it for real. So gonna have some fun make a game so yeah awesome yeah we we talked about this before um two-ish years ago i think i'm i'm double checking yeah i believe i'm gonna say ludum dare but you yeah, we'll say it's something else.

How do you pronounce it again? Dari? Ludum Dari. I forgot what the name stands for. Okay. Yeah, it was episode 146. We talked about it. Yeah, that's right.

That's why I don't remember it. Hey, I have a question for you guys. This is a very serious question. Is it really a joke? No, it's not a joke. I don't have a joke. you guys. This is a very serious question. Is it really a joke? No, it's not a joke. I don't have a joke. Oh, come on. Be a joke.

But you guys like onions? It's a joke. Ah, yes. Here we go. No, no. Do you like onions? No, they're gross. You don't like onions?

Really? What about you, Allah? Is this like when it seems like nobody likes onions? Because wasn't that like a podcast or something? No, I don't know. No, this is a serious question. Do you like onions? I do. I can't wait for the punchline.

Do you ever cut onions? There's no punchline, I swear. Do you ever cut onions? Underwater. What? I don't know what that means. Does that keep them from making you cry or something? Yeah, it does.

It keeps you from crying. Like what? I don't understand why that was so funny. Like the looks that I, if the audience could have seen the looks that I just received. I thought it was some secret message. Well, the reason I ask is like

I was cutting an onion tonight and you know how like there's the flaky layer on the outside and it's the part that you're trying to get rid of. And then there's a really thin layer right up underneath that that's kind of a pain in the butt to get off. But if you can do that,

you could salvage like the really big, thick onion outer layer. Like do you get it? Like when you're cutting an onion, do you just like, whatever I'm sacrificing that, that really good sized outer onion, just so that I can get this thing off faster.

You spend the time to like actually get that thinner one. That's right there on the outside. Curious. Like how deep, i'm sorry i was putting a note there because i did find uh i was correct that nobody likes onions as a podcast um but but do you do i try to get like thinnest one off or do you try or do you just like sacrifice that big one yeah i outside? I don't care, I guess. I never put that much thought into it. I don't think I did until tonight, but I was cutting an onion. Now, you want to try.

Right? Yeah. I think I just tossed the outer one because it's kind of thicker and kind of gross anyway. I mean, they're all gross. What? It's not gross, man. It's better in the middle. There's no bad part of an onion.

I agree. I don't care what that other podcast tells you. Onions are great, especially sauteed. Oh, dude. It's like now purple onions. I can totally get behind the fact that you don't want to eat those things raw because they stick with you for a couple of days. But yeah. All right. So at any rate, I just had to ask that.

It was a little bit off the wall, but I had that thought tonight when I was cutting an onion. And I was like, man, I wonder if I'm the only one. I really thought we were going to a punch line. Like, I'm still. I didn had to ask that. It was a little bit off the wall, but I had that thought tonight when I was cutting an onion and I was like, man, I wonder if I'm the only one. Man, I really thought we were going to a punchline. We're going to get James Tadar on the show. That guy really knows his onions. Oh, does he? Is he an onion guy? All right, we're going to make this happen.

He really knows his onions. For all the new listeners, I promise you it doesn't get any better than this. You just heard the best material. This is as good as it gets. Every episode is like that. So, yeah, I'm sorry. All right.

So I guess we can get into the meat of it this time. Oh, I see what you did there. I thought that was a throwback to my hamburgers. Oh, that's it. Oh yeah. I hadn't even, but that's not what you did. So, okay. I guess I didn't see what you did or I saw what you didn't do.

You saw what I didn't do. Yeah. That's really good. All right. So, so we're, we're back into the get conversation here and we failed miserably on part one. I think we redeemed ourselves a little bit on part two and, and I'm really hoping hoping that in this one this kind of drives home some of the points that we've been talking about because we are committed now i see what you did there so speedo just to kind of reiterate a little bit from uh last episode and this is one of those rare episodes where if you haven't heard

the last one you actually should go back. Yeah, totally. Everything else would make a lot more sense. But last episode, we talked about how Git, it really boils down to just blobs, trees, and commits. And that's it. That's it. Fundamentally, that's it. So if you can wrap your head around that, even if you've been using Git for years like we have and had no idea, or at least I didn't have any idea this is what was going on behind the scenes, then yeah, wrap your head around that. And we have a link here in the show notes to this section because this will be helpful for you to follow along

because we're going to cover some commands at the bottom. Like we're going to talk about them only so that you'll have an idea that they exist. I mean, there's no way you're going to remember all this stuff, but it'll be nice to know that they're there. So the first thing is a commit can have one or more parents. I think we talked about this before. If we haven't. Yeah, we did some experiments too. Oh yeah. Well, I mean the first example of like a year, you're like, well, why would a commit have more than one parent?

But every merge you've ever done is an example of a commit that has more than one parent. Right, right. When you're bringing two together, that's when it happens. So what they said next is for this reason, these commits can be treated like branches because they know their entire history. Right. So you can reference it by doing a get branch dash V. You can actually see the commits that are being referenced in that particular branch at any given time. Wasn't that the same thing that you used as a tip for the seeing where you're, uh seeing where you branched from if you did... Dash VV.

It's actually more verbose. But yeah, it was. It was based on if you did your checkout and you did a dash T to track it, right? Correct. Okay. And if you wanted to see what you were tracking, then you could do a get branch dash VV, and then it would show you which branch it was tracking from. Would you like to know which episode that was? That's been a while back. Yeah. One 49. Oh, is it? No, I don't know. I thought you, I thought you had it. No,

I thought I did too. And then I was like, Oh wait, no, that wasn't it. So I don't know. I'll have a link to that one in the show notes because there was a tip of the week where Alan had said, hey, here's an easy way that if you want to. The premise of the tip was if you ever are working in a branch, you're like, wait a minute, where did I branch from? Especially if you're the type of developer that might have like you're juggling multiple things at one time. And so you have multiple branches and you're like, wait, where did this branch start from? Then that's where Alan's tip came into uh to play yep i'll find it so the next thing that we have here and this is this is another one if you remember that get their blobs trees and commits a branch is just a named reference to a commit

yeah and we kind of hit on this last time but you know um just to like they they the author super drills this in to it because he starts it off by saying say it with me right right he was actually pretty funny i mean honestly this this technical document that he's written is is entertaining while it's got a ton of technical stuff in it he's actually a pretty good writer. So I recommend going and checking it out. Yeah, I definitely did appreciate, uh,

you know, the, the humor here and there interjected in. Yeah. So this is where they call out and we talked about it on the last episode, a branch and a tag are mostly the same thing. And I think outlaw called it out explicitly on the previous episode is the only real differences in a tag. It will only ever reference that one commit hash that it did.

It pointed to originally, whereas with a branch, as you commit more things, that branch now references a new commit, right? That doesn't happen on a tag. Yeah. You're we, we referred to it as alias, an alias. It was, it was constantly being moved along. And I found by the way, where that reference was to the, uh, um, that get tip. And it was episode one 82. If you were curious to go back and listen to it. Okay, cool. So we just said that branches are really just names that point to a commit. It's the latest commit in that particular branch. And then tags have descriptions that also point to a commit.

But in that case, the commit can't change. So yeah, they made a point of calling out like, you know, these two things are very similar, but tags have more descriptive metadata about them than a branch does. Right. You can actually put a message on them as well, right?

As opposed to. You can annotate them. Yep. Yep. Yep. So they're a little bit more powerful. Yeah, it is not powerful. You can add more descriptiveness to them because it's not supposed to change.

Right. It's like the marking a point in time. Yep. So they say, knowing those two things, you actually don't need branches or tags technically, right? Like you could do everything if you just wanted to point to hash IDs all the

time. If you were feeling fairly nutty and somewhat insane, right? I don't, I don't, is it really all that insane listen i need some help if you if you wouldn't mind checking out my branch uh just or in my i'm sorry hold on let me change my vernacular here if you wouldn't mind checking out commit id uh d738125qrz and um tell me when you have that checked out you got it the first tell me i don't have to repeat that again you only have to type as much as it makes it unique that's right that is true well in my repo because it was so big i had to like say all those letters yeah so now they go they go into a couple of useful commands here that uh honestly i don't think i knew exactly how

they worked in the past they always did what i wanted them to, but that's because I always was very, I knew the situation where I wanted to do it. Right. So the first one is get reset dash dash hard, and then the commit hash. And basically what they say here is hard says to erase all the changes in the working tree, whether they were registered for a check-in or not, and reset head to the point to point to that commit hash that you put in there. Right. So that's kind of important. And outlaw, you want to elaborate on that a bit?

Well, I mean, he does make it, he does call out that, you know, the way he's doing this is dangerous, right? Because he's basically repointing head to a very specific commit.

So he might, he could have technically already made like, you know, five new commits and he's going to like undo that by going back to a very specific one. I have definitely used a variant of this where instead of specifying a, a commit ID, I'll just use head instead where like you know i'm just trying to like undo what i currently have staged or whatever or you know changed and whatnot and and it's just like an easy way to to get back into that state so i get reset hard head but um you know he in his example he's taking it a bit further. Like it's, it's a little bit more extreme.

Yeah. So that get commit hard heads that the outlaw just said is that's basically, Hey, everything that I've done since I had my last commit checked in, I just want to wipe it all out and go back to where I was the last time I committed. Right. And it, it sort of cleans everything up for you. So it too is dangerous. But you're not losing your commits.

You're not losing your commits, You're not losing your commits, but you're losing any changes that you've made that you have not committed at that point. And, and I don't think there's any undo unless your IDE stores like local histories and stuff. Right. So,

I mean, not from a get perspective. Well, well, okay. So from a get perspective, I don't even know then maybe technically, cause you could probably go back to your ref log and pull out like the things that were like blob.

Like if you had staged something, then one of the things that we learned was, you know, you would technically have a blob created. It's just, you know, it, it, cause the, when you, when you do the get ad, that's where it creates the blob. So technically that's in there. And so maybe it's leaving it there. I mean, I don't know. This is speculation on my part.

Maybe it's leaving there and you're relying on the garbage collection to later purge it because it's not referenced by anything. Because one of the other things that we learned was that like, you know, anything that's not pointed to by some part in history will eventually get purged. Right. So, you know, maybe, I not pointed to by some part in history will eventually get purged. Right. So, you know, maybe I don't know. We would.

I'm about to try it right now. OK, go ahead. OK. Yeah, I've been having some fun. So so in example, I've got a brand new repository. Right. So my if I look at my objects folder, I've got nothing. And if I create a file, a dot text.

Right. So I save it. Still nothing. I add it. Now, just like you said, now I've got an object in my objects folder. Right, which makes sense. You've got the first two letters and the rest of the items because it's there. Now, if I do a get reset hard with no head, then I would expect it to get rid of that folder.

Let's see what happens. Make sure I hit refresh. So it is still there. In the objects folder. It is still in the object folder. But if you do a get status, it doesn't show up as staged. It shouldn't even show a change there anymore, right? Because if you did get reset dash dash hard,

the file's not even there anymore. Well, yeah, but the point that I wanted to make is that this is where the dash dash hard comes into play though, right? Because if you don't do the reset, if you've staged a file and you do a reset on it without the dash dash hard, then it unstages it and and brings it back it's like oh do you know here's like a uh you know an unstaged change right right but your file is gone right jay-z but your object id is still there so the object is still there and it's

i mean it's got stuff in there and all i do is add it so what i'm going to do now is a get cat file i'm going to tell it that it's a commit. But wait a second. In your working directory... But it's not a commit. It's a blob. Right. It's a blob. But in your actual working tree, your directory, that file's not there anymore after the git reset hard, right? The file is gone, but the object is still there.

And I believe that if I could remember how to look at their... cat-t? No, that's the type. cat-file-t blob and then the commit id of or i said commit id i meant the shaw the shaw right yeah so it is not liking that so we said get yeah like i'm questioning whether the file's really there here if the you know i'm hitting refreshing code but yeah i see uh one folder under my objects, 1A, the first two letters of the item from the hash.

And I believe the content is in there, just what I had in the file. But, yeah, if I do get cat file, and there was a way to say commit. It's get cat-file blob, the word blob, and then the hash ID. Oh, no dash T? No dash T. Did I have that wrong? T is the type. The T tells you hash ID. Oh, no dash T? No dash T. T is the type. The T tells you the type. Oh, okay.

If you wanted to find out what type it is. It's definitely not going to be a commit because you haven't committed it yet. Yeah, you're right. And yeah, so there we go. So it was user error before. It is a blob, not a commit. I did get cat file blob. So it is still there.

Yeah, and so that's interesting. So I did get reset hard and the stuff is still still there. Yeah, and so that's interesting. So I did get reset hard, and the stuff is still there, even though it's not in my folder. So the new file I just created is totally gone, but the contents of the blob are there. And this is going to get cleaned up because nothing's pointing to it. Eventually. I don't know when.

Right, 90 days. It's cleaned up. Maybe, well, 90 days. Is it 90? Really? That's what I thought we recalled at the start was it was like, you know, the default was like 90 days if it wasn't pointed to by anything. Wow.

So you want to know what's really cool about this, right? Like if we took this thought exercise a little bit further, I don't know if you want to have to go do this, but that blob ID is in there. You could actually, that tree should still be there as well, right? So you could potentially. Well, the tree isn't going to be there because nothing was committed uh nothing he's only added it so this is where i was saying that like when you when you did that ref respect and i was speculating that maybe it was still sick around and then if you wanted to go back and find it because like let's say that let's say you're

now working in like a large repo right so you you know what the way that joe just got to that shaw would be impractical because you might have you know, what, the way that Joe just got to that Shaw would be impractical because you might have, you know, a whole bunch of those in there, right? Yeah. And, and so this is where like, it's definitely coming up in a future chapter, but that's where the ref log would help you. Cause you could go back through the ref log and find what was going on in, in, it would give you that id so very interesting right like you haven't totally lost your work although it's sort of just floating out there right now and it would be a bit of a pain to go get it well yeah and there's nothing to tell you

where that file was so all it is is a blob so even if i were to um say like have that committed and like um you know if i were to go and make some changes to that file and it's going to get its own separate blob, there's no way to automatically put that stuff back together. So you as a human could go in there, figure out what it's supposed to be, what you intended it for it to do and kind of put Humpty back together again. But there's no way for it to do it.

Yeah. And that goes back to what we said in that previous episode where a blob stores, no metadata, right? It's only the content and it's in its size. And then, and then the hash ID is the, is the hash of those two things. I think that's where, like, I think I'm pretty sure it was this, this book, the get from the bottom up. Uh, I don't know if we said that already, but if we hadn't, uh, we'll definitely

have some links to it, but yeah, get from the bottom up. I believe it was in this book though, where they also mentioned that like, it's really hard to like truly lose stuff and get you know and and unless you just let enough time pass that things do get garbage collected out but now i can't find the i thought i could have sworn that we read it in this book and now i'm not finding it so i don't know that's where i'll just go to the google machine and be like what is it all right so So hopefully we've drilled that in, right? Like the git reset dash dash hard. And then if you go ahead or leave it off, that's sort of getting rid of everything except your object ID still hangs around or your object hangs around in the git folder for a little while. So that's different than the next one.

The safer way to do this is git checkout and then a SHA-1 of a commit. And this is similar to the dash dash hard, except any changes in your working tree are preserved. So what this is saying is, hey, check out things from this particular commit ID. But if I've made any changes in my local directory, don't blow those away, right? And so it's sort of a safer way to get back to a previous state that you were looking at for that commit without destroying what you already had there.

You know, what's funny is Git reset is really fast, right? Like I've reset too many times and it goes really fast. I don't know how it reconstructs things so quickly because if you just watch these blobs build up, you'll see one particular file, if there's been a lot of change to it, you end up with a lot of blobs.

So I assume we'll get into kind of how it can be so efficient restoring, but if you think about if you were programming your own version control system right now today, how you would do that, that's not easy to restore to a point and to do it perfectly. Really quick. Yeah, that's going to vary based on the size of that repo, though, and how many changes you have.

But I've never had a slow git reset where I'm like, oh, it's still resetting. I can help you with that. Hold on. Just to close the loop on the garbage collection, defaults to 90 days. Okay. And I think in a previous episode, too,

I had questioned how it manages to find all the objects that aren't referenced. And our buddy RefLog comes back again to save the day because if I'm reading this correctly, it's using the RefLog to find the things that, uh, you know, that, that have expired or,

or the things that it needs to evaluate. I guess let's start, let's say it that way. Yeah, we've actually, uh, coming up in the notes later, we've got a bunch of commands that we'll talk about different ways you can refer to commits and like,

uh, operations you can perform on them. And one of those is like finding diffs between two things or finding, uh, commits with the parents and, you know, all sorts of interesting stuff. And so, yeah, I i mean there's these tools that you can use and it makes sense when you dive a little deeper and figure out what get needs to do oh totally the the commands

cleared up a lot of stuff for me and things that i've seen and stack overflows and whatnot over the years that i was like all right i'll run that i don't know what it does. Um, right. Yeah, exactly. So on this checkout though, there's a very other important difference other than, other than a get checkout, not blowing away your current working tree changes. There is one more super important thing that you have to understand about it is when you do a get reset dash dash hard, it changes head, which remember that's just an alias that points to the latest commit and whatever branch you're in, right? When you do a get checkout of a hash, it does not repoint head. So if you were basically working on something, you had things going on, and maybe you're three

commits ahead, but you wanted to get some of the things back from a couple of commits ago, you could say get checkout. And then that commit hash back then, it does not change your head to point back to that old commit ID. It leaves it where it is. Whereas a get reset does it repoints your head to whatever hash you used or, you know, so that's really important to know. So that's not something I knew before. I've done get checkouts before to pull in the latest version of a file, but I'd never actually done it to a previous commit ID like that. I want to make sure though, that like we're seeing this correctly, because if you do a get checkout of a commit, if you were to go in like cat the value of head of that file, it has a commit ID in it,

right? It, whatever commit ID you checked out. And if you, if you check out a branch, then the, and you cat the same head file, then it has the ref,

the name of whatever that branch ref is. Right. And so the branch is the one that has the, the commit ID in it at that point. So the file head is just saying like, Oh, you need to go find this other file and it'll tell you what commit ID it has in it. Right.

Yeah. I think, I think what I'm saying is if you were to do a, um, you know, find out what head was, it would still be whatever that branch's head was pointing to before you did that get checkout. Well, I guess what I wanted to say, what I wanted to clear up, though,

is it's not changing head in those two scenarios to have the commit ID. In one scenario, it's not actually changing the file head if you're on a branch. It's changing the branch, the file of the branch. Correct. And that gets confusing, but think of the branch as the name of a file

because that's the way Git's treating it. Exactly. If you're checked out to a branch and you do the git reset, then it's changing the file that is named whatever your branch is. Correct. The commit ID that it points to. But if you check out the commit ID, it's actually updating the file head.

The file named head. Yeah. Yeah. So absolutely. And I did a couple of experiments here. So just like you said, like if you check out and then it's going to update that file. But if you do the checkout, the difference between it and the reset is that both will change the head, but one won't lose any changes you've gotten when you're working directory. Oh, okay.

I missed when you said that. i don't think so if i do uh get checkout main then it changes uh the head file to say ref you know refs heads main if i do check out of a commit it's going to change that head to point to just the commit hash if i do a tag it's also going to do the commit hash one two three four five six now if i do a reset uh then uh and dash dash hard then it's going to make sure that head still points or that uh yeah the head the head doesn't change but it resets the files in your working directory correct that's what i was saying so when you do when you do a reset dash dash hard, it repoints head in your branch to whatever that commit ID was that you put in there, right? No, that's where the wording is losing me. If you do the get reset dash dash hard with the commit ID,

it's not changing the file named head. It's changing the file named what your branch is named. So listen, this is what it says directly from the paragraph okay um if i pat uh the difference here is i've changed blah blah blah if i pass dash f blah blah check out only ever changes the working tree whereas reset dash dash hard changes the current branches head to reference the specified version of the tree. Yeah, that's the file that is named the branch. Because remember, it's refs slash heads slash branch. Because if you were to go digging through your.git directory, right,

there's a file that is the name of the branch, right? Am I remembering this wrong? Yeah. Yeah, no, it's under refs head. I just said it a second ago. But so a branch, remember, head is just an alias to the latest commit in a branch.

There's two things. No, that's why I'm trying to be super clear here. There's a file named head, okay? And that file is the alias that Git uses throughout. Like it almost uses the same as an environment variable.

It's used all over the places like where you can do a get reset hard head, for example. Right. But there's also in the refs folder, there are heads and one of them is your branch. So like if you were to go poking around in that, uh,

and I'm trying to like get in there now, it's like, Oh look, refs, heads, one for master, main, whatever. Yeah.

And so then if you were to go into your.git directory into a folder called refs slash heads, you will see one per branch that you have created. And those are also files the same as the file named head, right? And in the contents of these files that are named, whatever your branch is named, it has the commit ID that currently represents the head of that branch. So when you check out a branch, the file, the head is used way too many times in this analogy, in this description, the file that is named, when you check out a branch, the file that is named head gets updated to say refs slash head slash whatever the branch name is right and then that file refs slash heads slash let's say trunk is the name of your branch right refs slash head

trunk that file named trunk gets updated with whatever the commit ID. So as you add a new commit ID, it gets, it updates that you add a third commit ID. It updates the trunk file again. And now you decide, you know what I want to do? Uh, what was his name? John said to do this,

get, uh, reset dash dash hard and specify commit ID. It's updating the file trunk and named trunk in this example, because not changing the file head, right? Yes, yes. The file named head is just simply referencing that, hey, if you want to know where to find the head, you should go point to this other file. Head is always an alias that points to whatever the branch that you're on, whatever that thing is. Except that's where it gets different because if you check out a commit or tag,

then the file head gets updated to a specific commit. Oh. That's the distinction I'm trying to make. Oh, so you're saying it no longer points to the branch. Right. The branch head. Okay. And that's where you get into a detached head state.

Yeah, and you could tell, if you actually just watch that file, like in VS Code, like, it's really great about updating, so you can try this stuff. By default, head will point to the word ref colon space and then a directory path, ref heads master by default. If you do, if you check out a commit, it just does a commit hash, like no preamble, no nothing.

But what's funny is, like, I had some fun, and, like, I actually changed, like, the paths in this, and it totally works. bit hash like no no preamble no nothing but what's funny is like i i had some fun and like i actually changed like the paths in this and it totally works like you could just like make a path like a folder anywhere you want in here with a file in it you know put a hash in there and update this head and it'll take it it's pretty because it's always pointing it's always looking at those files anytime it's doing anything right yep okay so that wasn't clear in what that paragraph said there so that's why i wanted to clear that up, because the word head is used way too many times, and it's confusing

because he's referring to the branch's head, not the file head. And where he made it, where it got extra confusing is that when you're reading this, there's this annotation where head is always in all capital letters. Right. And so you think that he's referring to the special alias in this example because he capitalized it again, but he's not. It should be lowercase in this specific example or this specific thing, which by the way, this is, we should say this is on GitHub. You want to,

you want to make a commit and, and help contribute to, uh, um, I can't pronounce his last name cause I always get it wrong. I'm going to try again. John Wigley. No,

did I get it? Tell me I was closer. That's good. Uh, vaguely. Dang it. It's always the second letter has the if it's if it's german right it's so okay that's good why would i think a w would be pronounced like a v

well well in german it's a w is a v and then you use the second letter as the as the so if it was ei it would have been vaguely but here it's it's Weigli. Because it's by E? Yeah. So it's B, Weigli. Anyways, I don't know if he's German, but that's, you know. So Alan's going to school me in proper nouns. I lived in Germany for a minute, so I don't know much about it anymore. But anyways. We should do a book on – that should be our next book on proper nouns,

how to pronounce things. There you go. All right. So that was actually really useful because, again, the page there did not make that clear. And like Outlaw said, everything on the page is referencing head in upper caps, and that is generally meant as the alias, right? Like when you're doing any git commands. File named head. Right.

All right. So good. All right. So the next part is some some simple hopefully simple concepts to grasp here if a kid if a commit has multiple parents it's a merge right um outlaw mentioned that earlier and if a commit has multiple children then it represents the ancestor of a branch so pretty pretty basic stuff and they both make sense if you've ever seen their little bubble diagrams

where they show the circles and the lines and all that. Now, can I share something that I should be embarrassed to share? But I'm going to do it anyways because that's what I do. Hey, didn't you just earlier say we don't always need to share everything? Oh. We decided to cut that part from the show. Yeah, we did cut that part. You'll appreciate this one though.

This isn't some kind of weird reference like what Joe would bring up. Sorry. But yeah, that second statement took me so long to figure out like, wait, what does he talk on it? What does he mean here? Like if a commit has multiple children,

it represents the ancestor of a branch. And I'm like, for the life of me, like, what is going on? What is he trying to describe here? And I don't know why it just wasn't clicking until eventually, I think it was like, I think I eventually gave up and went on because that was like the parent that like literally that chapter ended on on that statement or, you know, around it. And I was like, well, whatever. So I went on to the next chapter or maybe it was on the one after that. And then I'm sitting there.

It was like, oh, wait, I know what he was talking about now. And he's saying that if the commit has multiple children, it's representing the ancestor of a branch. And I was like, okay, if your main development branch is called trunk and alan creates a branch called alan and joe creates a branch called joe and i create one called michael then we are all our our and we committed at the same time we were i'm sorry let me rephrase that we created our branches at the same time off of the same commit id then that one from trunk would all have these children,

these three branches that are children of it because it's the ancestor branch that we branch from. And I'm like, I don't know why that didn't click with me like immediately because the first one did, if it had multiple parents and I'm like, Oh yeah, of course.

You know, what's funny is you got all the head stuff where that was all mixed up and it wasn't as clear as it needed to be. But this this very basic thing of parents. Yeah, I don't know why it just didn't it. It you know, I don't know. Hey, but in fairness, like again, we have the link here. It's the beauty of commits is this particular page. If you scroll down to the very bottom of that page,

they have a chart there, a graph or a picture. I don't know, um, of this whole notion. So this whole head and where things are pointing to and ancestors and children and all that kind of stuff. So it's kind of nice to be able to visualize it in terms of what these

are. So, um, definitely check that out. And you also just look at any uh git folder so uh git uh sorry vs code actually hides the git folder the dot get folder by default but you can change that i forget how i did i had to get to google just like a list of folders that i'll not include by default it's cool just to watch those things change but once you get past like

one or two files and get uh forget about it because like looking in the objects directory like oh i've had to create so many different repositories uh during these last couple episodes just because like oh yeah me too once you do one or two and you know like and then all the changes on them yeah i mean it's impossible to see what's going on so i'm constantly just creating new ones and now i have a whole git folder that i blow away from time to time and then start over again that's the way to do it yeah and you can like you you mentioned about the cleanup like you can run the garbage collection manually if you wanted to um but you definitely like run the risk of like well you know if you were in a situation where you might want to go back to something then you can't yeah here's a

tip for you by the way never delete your branches not branches. Not if you're local, not off the GitHub or GitLab. I don't like that. Yeah, I was going to say. Sorry, I was trying to trigger a lot. Yeah, no, you're definitely triggering me. Thank you for doing that. No, because, okay, well, tangent alert. Because some people might be saying like, yeah, no, I totally agree.

Don't delete them. Why would you care? And, and maybe somebody else is out there, but like here, here's a reason why you might want to care because depending on what your build automation is, that's just that many more heads that it has to go. And you know, uh, the build automation might have to go and inspect because in the case, I'm going to pick on Jenkins for a minute. Like Jenkins is awful about the way that it does it, or at least with the plugins that we were using for it, because it does it serially. So if you kept your 50,000 branches around and it's like, oh, well, let me go check these 50,000 branches. And you're like, but I just added a new one. Why don't you focus on on it i don't know about that new one yet i got i got these first

50 000 i gotta get to these my first 50 000 customers i'll come back to you so it's like if you clean up after yourself do you do something like you're like oh crap what was the name that branch that i was using the other day let me just do get branched if you've got like 50 000 in there good luck yeah but also from just a from just a compaction kind of point of view, if you have all those branches out there and you know, a lot of them might represent things that you don't merge in that you have no intention of merging in, or maybe it's like you, maybe you had all intentions of working on it, but now three years have gone by and you still haven't merged it in. But guess what?

Because it's being pointed to garbage collection is never going to get rid of it. So now you're just bloating the size of your repo. So this is holding all those objects around because there are references to them. Yeah. And for the, for most people who aren't like dealing with it on the server side,

they're gonna be like, I don't care because you're not going to have, it's not bloating it necessarily for you. You're melting the polar ice caps. Thanks. But there was another point that I was going to make, tier two, with the commits and the multiple parents, though.

Because Git does this thing called an octomerge. Because we typically just merge two commits more often than not. But you don't technically have to. You could you could merge multiple things if you wanted to. Right. I don't know that I've ever done that. So so that multiple parents thing, the thing that I wanted to call out there is that um you know it's it's not two like

it's weird that they call it parents in this book because you know obviously you know we think of parents and we're going to think of mom and dad right like we're going to think of two right but really it the point that i wanted to drive home is in git, it doesn't have to be two. It could be as many as you want it. And that's why there's the Octocat. Okay. Because it's not just doing two merges. That's why the GitHub logo is the Octocat is where I'm going with that. Oh, I didn't know that.

Because it's Octomerge. Interesting. All right. So to wrap up this particular section here, just reiterating again, Git is a collection of commits, each of which holds a tree, which reference other trees and blobs, which store data. Like, that's kind of it. Now, there's a bunch of other stuff wrapped around it, but that is how the things are stored, and that's the basics there. All the other things you can get are named concepts, but they all boil down to what we just said in the basic storage stuff.

And then I already mentioned that image on that page. Go take a look at it. It will help you understand some of that stuff. And then you'd be like, oh, yeah, ancestors. I get it. Outlaw was just silly. Parents. Grandparents.

He was just silly goose. I don't understand. Yeah. was just silly parents grandparents he was just silly goose i don't understand yeah i think actually they even show well squares are blobs so never mind uh that are triangles were the new so okay i was going to say that they show like one with a three a three-way merge but it's not no that'll have it so all right well uh let me go ahead and say before joe makes it weird and jumps in here and says this. Because look at this mom on his face. You know he was crafting something weird to say. We're like, hey, I'll tell you what.

If you give me a two-star review, I'll buy you a cup of coffee and be your friend for life. Pumpkin coffee. Yeah, pumpkin spice. No, but seriously, if you haven't already left us a review, we would greatly appreciate it. You can find some helpful links at www.net slash coding blocks. Wait, no, that's not right. I said www.net slash coding blocks. That is awesome.

Why did that sound right? We're registering it tomorrow. Somebody bought the domain www. They had to, right? It's got to exist for sure. Okay. So I'm going to try this again. Keyword coding blocks.

.net slash review. There's some helpful links there. And, you know, we've said this before, but, uh, we really do appreciate reading those. They always put a smile on our face. You know, we get, we get, uh, you know, people write in either by, by reviews. Sometimes we get them through emails. Uh, sometimes it's things that, you know, people hit us up on Twitter or in Slack or wherever, you know, whatever's convenient for them. Cause we're, we're, you know, little social butterflies. We're in a lot of places, but, uh, you know, and we hear some of these stories that people

share with us of like how, like we touched their lives in ways that like we never could have envisioned. So it really does mean a lot to us. And, uh, you know, if you've left a review, you're tired of hearing me say it really does mean a lot to us. And, and, uh, you know, if you've left a review, you're tired of hearing me say it, but we really do appreciate it. And I just wanted to like drive that point home and,

you know, um, you know, let you know that it wasn't going unnoticed. So, all right. Uh, that was not weird.

I appreciate that. That was, that was not a weird ass. See, that was good. That's what happens when Joe doesn't do it. Yeah, it's totally fine. Joe doesn't do it. It was totally fine.

Really appreciate it, y'all. He went Southern. That's good. It was almost like Mr. Mackey, I thought. Echoes on 97. WMFE. ASMR Southern. That's totally not how that guy sounds, by the way.

I don't know why. I've always been terrible at accents. Okay. Okay. Russians. Okay. Get a pie, fry, or coffee. All right, so how about we play another round of Google Feud? I like it.

All right. Let's do it. I don't know. How would they? Let's play google feud i guess would be about as close to um although steve harvey isn't the one that says uh the family feud thing so i don't know who does that but um i'm gonna i'm gonna be i'm gonna try to be as good as that although you know i'm not gonna do what was the the original guy's name for family

feud richard something oh he was really creepy, dude. Yeah. Yeah. I'm not going to appropriately grab our shoulders and stuff. Yeah. I'm not going to kiss you or anything like that. Cause that was like weird. So here I put, we're going to do it a different way though this time instead. Cause like the last one was specific to get,

but this time I'm going to do it a little bit different. So you're going to pick one of these categories. And so you guys can see it here in the show notes, but for those listening at home, the choices are culture, people, names, question,

animals, entertainment, food. I'm feeling lucky or question of the day. And by to tacos rules of engagement, I believe Joe first on picking today. Thank you. Yeah.

Yeah. I'm feeling lucky 25%. Wait. That's not how that goes. So, okay. He wins. All right. I finally won one.

All right. So, we're going with I'm feeling lucky. Here we go. Feeling lucky. Yep. So, I got to make sure it's also appropriate. All right. So the question is who was the voice of blank? And there are 10 possible choices and you will give me your choice.

And whoever gets the highest choice wins. Darth Vader. Okay. So I have Vader and Batman. So I so I'm gonna I heard Joe say Batman first so I'm gonna say Batman who was the voice of Batman oh that's not even on the top 10 I'm sorry dang Darth Vader I I feel good about this one good I feel good about this one darth vader the number two answer alan wins it who was number one uh okay then let's find out who was the voice of buzz lightly buzz like your recency binds yeah come on that is buzz buzz buzz buzz light year all right so do we get to pick one now okay yeah we can do another round but i'll just finish out Come on. That is. Buzz, buzz, buzz, buzz. Lightyear. All right.

So do I get to pick one now? Okay. Yeah, we can do another round, but I'll just finish out the number three, Fred Flintstone. Number four, Alf. I don't think that's recency bias there. No. Another one from Blast from the Past for the fifth one, Kit. Wow.

From Knight Rider. Yeah. Wow. There you go. All right. Wow. From Knight Rider. Yeah. Wow. There you go. All right. Man. No Batman. Come on.

I immediately thought of Batman, the animated series, which, yeah, not a great choice. But Mark Hamill, by the way. Yeah. Anyway. Oh, wow. Scotty in Strange New Worlds. Wow. The Modern Civil Rights Movement.

That's a random one. Okay. Gizmo, Winnie the Pooh, and Charlie on Charlie's Angels. Like one of those got super serious. The rest of them are like all light and fun, and one of them was like super serious. So let's try the next round. All right. Let's do.

Oh, yeah. I forgot. You were going to pick a category. Let's do culture. Culture. Okay. I'm going to pick a category. Let's do culture. Culture. Okay. I'm out. I'm out.

That's hilarious. Culture. You hold your pinky up when you drink the martini. That's culture, right? Well, let me... Pumpkin spice. Okay. We'll try this one. I don't know where Google's

going to take me on it, but hats for like a hat like you put on your head. Hats for baseball. Baseball. Church. Church.

Church. Yeah, man. People wear some interesting hats to church. I got a – baseball was not on the list, and I'm going to type it again just to make sure I didn't mistype it because how could baseball not be on there? And it wasn't. Church. Wow. I thought that was number one, Alan.

I will give you credit. Yeah, same. Hats for church not on there. I will give you credit. Hats for church. Not on there. Imagine. Kentucky Derby. Yeah, these weren't even really that good. Oh, hats for big heads. That's one I Google all the time. Yep. Men, women,

big heads, cell, dogs, cats, kids. Yeah, they were all like very, you know, they weren't. Yeah, they were all very generic. Dogs? They weren't funny. That's for dogs? Sure. Like for Halloween?

Come on. What? Look, Joe's about to mess his dogs up. Yeah, these are super cute. Oh, my gosh. Oh, my gosh. They're so cute. I can't take it.

Well, you wanted to get back into Git then? All right, let's get back into Git. Git it. All right, this is where things get... Hairy. Yeah, I mean, so I don't think anything was going to be any hairier than that head, head, head thing was. Yeah, the head of the head of the head point to the head and updating the head.

I will. I do want to prefix this section though, because this section is really like in your podcast player, most podcast players, you can, you can see the show notes that we published along with the episodes. You can follow along with what we're saying. If not,

you can go to www.codingblocks.net slash episode 192. You can follow the show notes, or if you're reading the Git from the bottom up book, you can follow along in this chapter that's called a Git, I'm sorry, a commit by any other name, because the point is there are a lot of examples that the author gives here that will say without like you know harping on the syntax of it so much i think would be a fair way to say that because it it can get hairy quick yeah but the key here is is knowing that there are these things that you can do and understanding that when you see them, what they're doing, it will actually help you out a

lot. So we'll cover a few things real quick. So, um, they already said the key to really understand get in general is just understanding the commit topologies, right? Like we've been talking about that quite a bit. Um, and then they say that learning to name your commits is sort of the way that you can really get good with using Git. So there's a few things. Right. The branch name. This is the name of a branch is an alias to the to in Git, like if you do all caps. Tag name, they said, is similar to the name that points to a specific commit. Difference is the tag can't change the commit ID, right? It doesn't move. It doesn't change.

Head is the currently checked out commit. It's whatever the latest is in a branch that you're on. Um, now this is, this is where some of the technicalities start coming in. So your, your hash IDs, their Shaw one hashes of things that they're 40 characters long. You can always check out or get to one of those things by just, you know, get checkout and then paste in that, that hash, the entire 40 characters. You can also, and this is what Joe said earlier is you can also check it out by using a much shorter version, like six or seven characters, whatever is enough to make that hash unique with those first several characters, right? It might be four. If you don't have very many commits on

your system, it might be six, seven, eight, nine, whatever. But you can do it with the shorter version. If you just created your commit, you could just do it with one. If you just created your repo and only had one commit. One character. Yeah, you totally could. Isn't that crazy, though, to think that on a large repo that six to seven characters are generally enough? Shows you how random it is, right?

Well, yeah. I mean, I still thought about that i was like well okay seven if you went with seven characters then you basically have uh what 36 possible you know uh 26 choices per you know because because there's no the uppercase doesn't matter here so yeah yeah there is a minimum by the way You can't actually do just one. Oh, you can't? It won't let you? Yeah, I thought earlier when I was trying to do that, I was trying to do that where I was just typing 1A and it wasn't enough. It looks like four is the minimum.

Okay. So they force it on you. Yeah, I don't know why, but I tried one, two, three, and then four. So there's another pull request opportunity for the book then. Because the book does say you only need as many digits of a hash ID as are needed for a unique reference within the repository. Hey, so Jay-Z, real quick. If I remember right, when we were looking in those git folders, it was like a couple of characters and then a dot and then some odd. How many characters are before the dot? Is it just two? Oh, it's it's a slash yeah two for the folder so like i'm looking at it

it can be hash for example it's d8488 and then a bunch of stuff d doesn't work eight doesn't work that makes that was the folder do you think four would be enough things it's like okay fine it's the folder in the first nope but d48 uh sorry 8, sorry D8 4 8 is enough. Okay. Interesting. So it wasn't the slash. I was wondering if it might have had to do with how it was storing things. Yeah. That's what I thought too. I don't know what it is. Okay. So you're saying that

it needed 3 or 4? 4 minimum for me to check out on my version of Git, whatever. Maybe that's changed. I don't know. Oh, that's a good call it too i wonder which version i get you're using all right so this this next one this is where things start getting interesting this is where i used to see stuff on stack overflow and i was like i don't even know what this is but i'll paste it and hopefully magic will work right so if you see if you see where it's got the name and then a carrot afterwards, the carrot tells get to go to the parent of the provided commit.

So, you know, go up one, right? Up one commit from the one that you referenced. If you do, you can start stacking carrots. So you could have name, carrot, carrot. You could have name, carrot, carrot, carrot, whatever. And that's literally just, Hey, go up to the next parent. Now here's something that's really interesting that you have to know about in outlaw called out earlier. If you have multiple parents, right? It doesn't just have to be two. You could have three, you could have four, you know, like he said, there's this Octo merge thing. If you say go up to the parent, it's going to go up to the first parent in the list.

So if you do name carrot, it's going to go to the first one. If you do name carrot, carrot, it's going to go to the first parent, then that parent, the first parent in the chain. So pretty interesting. Outlaw, you want to take the next one or Jizzy? Well, I was just going to say that if you had multiple parents, then you can specify in the carrot, because to build on what your example was,

the name of it, carrot, and then the number of the parent. So like, you know, in case that you only have typically two, and this is where like get also doesn't follow everything else in computer science, right? Because it starts counting from one, one. Yeah. It's not zero indices. So like what outlaw was just saying is you'd have name carrot too. That'd say, Hey, that doesn't mean go up to parents. That means go to my, in my parent list, go to the second parent that's up one level for me. So name carrot two would be that if you did name carrot three, that would say, Hey, go to the third parent that's just above me. So pretty interesting. The next one experiments here. Yeah like some of these things that like wrote

point to one or the parent or whatever like what if you don't have a parent uh i guess but if there's an error like what i expected you yeah that's that's what i mean you think same as like we saw if you emitted a repo and you do a get log right like it offset through through the error too yeah nothing there you know, the number of those, this is somewhat off topic, but can you think of an example where those number of parents would come in to play that you might need to know and care? Have you ever been in a situation where? I don't think so.

Let me rephrase the question. What's a situation, a Git situation, not necessarily specific to what we were talking about here with names, named commits, but what's a situation where there are multiple parents and you care to know which one of those you want to use? All right. I think so.

I would have a commit that's got, say, two or more parents, and I want to choose between them. If you're doing conflict resolution, maybe? I don't know. Joe, you got a guess? Still thinking about it. So I've committed. Same commit to two you guys are going to kick yourself when you hear my example because you're like oh i've definitely done this

or at least that's you know i mean both of your examples aren't the ones i'm thinking of so yeah i don't know cherry pick well i guess when i create a new branch no i don't know a cherry pick so if you want to cherry pick a merge you can't you can't cherry pick a merge commit so instead what you have to do is you can give it the merge commit id but then you have to tell it which one is the main line to pick oh okay yeah yeah. Yeah, good call. And so in that case, you know, you're going to see all of the parents are going to be listed in the merge commit

and they're going to be numbered from one and you're going to say like, you know, this is mainline. And it's weird too how it does that because it picks it by number instead of, you would think that it would make more sense to use the commit ID and say like dash M and then the first seven of the

commit SHA or of the SHA and instead it doesn't. It's like one, two, three and you're like, oh, I want number four as my main line and you do dash M4. So that's weird. Interesting. Alright, So this next one up, we talked about if you had the name and then carrot, carrot, you can accomplish the same thing with shorter things. If you don't want to start typing in 20 carrots, if you're trying to go up 20 parents,

you can do name Tilde and then the number of ancestries you want to go back. Right. So if you did name Tilde 10, it would go up to, you know, the 10th, uh, parent up the chain.

And again, this is always going to pick the first and, and the parent lineages it's going up. What is that? You know, I've not been able to get named to work uh it's because here the because here name is like the commit so so name is either going to be like head or the first seven of your shawl like that so that's what the author is using

to signify name here like he's using name generically. Right. Yeah. So I do, I tried like get log, uh, then there's a couple of numbers might commit. And then the tilde I've seen,

or not, not till the carrot. I've seen like head carrot. I think you can do head. I think you can do the branch name as well. Yeah. You could do the branch name, the tag name,

the head or the commit ID. Cause that's where it starts off. Like the, you know, he, the author starts off saying tag name, the head, or the commit ID. Because that's where it starts off. The author starts off saying, if commits are the key, because he's talking about how to understand Git, right? If commits are the key, how you name commits is the doorway to mastery, is what he says. And so you think about these commands, like these different ways that you can reference commits.

Like, oh, I'm on whatever my head is. I want to go, I want to know what it was i want to see a file or a diff or whatever from five commits ago and it's like well how can i get to that right then that's where he's saying the mastery of this thing comes into play where you could do like uh name tilde five to see the commit, you know, to see what was five commits ago. If you wanted to like look at a file from five commits ago or look at, you know, the log or whatever,

because like, let's take Jay-Z for example, right? Like let's pick on Jay-Z for a minute. We never do that, but you know, cause like Jay-Z is like a get, a get commit fool,

right? He's like committing all the time, right? Bang, bang, bang, bang, bang,

commit, commit, commit, commit, commit, commit. And then he's like, Hey, you know what? I know I did some, I know three commits ago, this was working. Right. And so this is where like, you know, you might want to do that diff against it. And he's the author saying like, you know, sure. You could go and do a git log and get that Shaw and look at the file that way, if you wanted to. But this is where he's saying the mastery of it would be like oh now now i can like elevate my my level by not referencing it uh by that commit i could do head totally three to get to something three commits go to like diff it or whatever right so i figured i was doing wrong by the way um in my various experiments i didn't realize that i had uh chopped all my

commits down to just one so i was trying to do the parent of my first commit and you had nothing yes yeah so that no matter what i tried the uh the carrot didn't work because i only had one commit and that commit didn't have a parent so it was another case where it was uh it was just an error so the command was valid but i got an error which is i'm totally fine and you know right it's just kind of funny like i'm so you still like modern software, you know, kind of like hold my hand a little bit and be like, now, now you don't have a parent. You can't do that. Right.

Now, this next one was pretty cool, though, because we build on this concept. We've established that the way the author is using the letters in A-M-E, you know, name here could mean multiple things, right? So like it could mean name Tildy 10, it could mean head, it could mean, uh, the branch name, whatever. And he says like, you could also append colon and the path to some file there, right? Which is helpful. Again, going back to the diff example that I was describing a minute ago if you wanted to diff something you know you could specify the file you could compare like you know two different uh in the in the book here he gives the example of like if i wanted to see what does my file look like from one commit ago versus two commits ago, then he does this get diff using head Tildy one colon file name,

head Tildy two. I'm sorry. I'm saying Tildy. Um, in his example, he's not going against the commits from one and two commits ago. He's going against the, uh,

no, you're commits of them, of them, the parents, the parents. Yeah. Two different parents. Yeah.

Cause he's doing carrot one carrot and carrot two. Right. But pointing to the same file name so so the point is that like you know we we've generically defined the name what name can be and now i'm saying you can tack on colon path to something to that as another way of like getting even more granular about what you're trying to go after. And that name portion of it can be all those crazy things that we talked about for where it could be named carrot, named Tilde, named, you know, whatever. So you can reference very specific things to get to those paths you want. So it's really powerful, right? And this

is the kind of stuff that I'm talking about that I've seen on stack overflow. And I look at it and I go, I have no idea what that's doing, but all right, fine, let's do it. All right. I think we're all going to have a better understanding of what we're doing now after reading through this,

this book. I mean, I got to say like, I really appreciate that John put this together. Yeah, this is, this is pretty, I say his first name only like,

like he and our best friends, like we get together, you know, Mr. Weakly. Yeah. Um, all right. Mr. Wiggly. Yeah. All right. So the next one is name, carrot, open curly, the word tree, close curly.

So this one's kind of interesting. You could probably imply or infer what it is. Instead of referencing the commit, you can actually reference the tree held by the commit if you do this command, I can't think of a reason outside of software that I'd want to do this. You know, like if I was writing get programs, but maybe there's a reason. Um, but pretty interesting. You can get straight to the tree object without some of the other, other commands that we had in the previous episodes. Yeah. I mean, I did, I did a show.

I did a get show head carrot curly braces tree and it showed me the content that I had committed there. Interesting. At least in this example, repo, I don't have a lot going on in here. I've made, like Joe, I've made so many different repos to like follow along with some of the stuff, some of the examples in there. Yeah.

That, you know, I have a few of them. But yeah, I had a decent amount of stuff in this one. So yeah. And he had a, so the author went through and gave like a bunch of different list of things here that we're talking about. And like some of those things are fine for doing it like a checkout or like a reset and some are appropriate for like logs and sometimes the things you would do don't make sense for one of those like uh you know doing a like you can do a range for example if you did like name one dot dot name two uh that's not something you do on a checkout right no but you would on a log like you were just saying you might even do it with a with maybe

a diff possibly these are a little bit confusing to me the next two yeah so i think i get them but but they're they both act very different but they're very close in in their syntax right so syntax, right? So name one dot dot name two that Jay-Z just said, it gets the range of commits that are reachable from name two, so the second parameter of this statement, all the way back to, but not including the name one commit. So it's just giving you a range of all those commits. As long as it can trace itself back to the first one, so name one, then it's going to give you a list of all the commits after name one. Right?

Yeah, I think I've seen this before. I think it's like when you do a rebase I, sometimes it'll do the little dot dots i've seen that syntax before but i never really understood what it meant you like get rebase dash i head tilde three you know say like i want to go back and look at three um but of course i don't have three commits in this one i could have sworn that where I've used that this was in regards to a diff, but he refers to it in the next one, in the next one with the triple dot. Yeah. So the triple dot is a little more interesting. So the previous one was like,

Hey, show me everything before name two, all the way back to name one, right? Like if you're doing a get log type thing in the second one, you have name one, triple dot name two. So here's where they say, like, if you're doing something like a log and you do this, it's going to give you all the unique commits that are referenced by name one or name two. So, so it's almost like a, a union of those things, right? Like if you're thinking of a SQL statement or something like where you're doing a union, it's going to pull out the dupes. That's kind of what this is doing.

Now it says for commands like a diff, the range is between name two and then the common ancestor of name one and name two. So if you're going to use these two that we're just talking about right here, the name one dot dot name two and the name one dot dot dot name two name two triple dot. Yeah. Yeah. Then you're you really going to want to understand what you're seeing, what what's pulling out of this, right? Because it could really impact your assumptions on on what's happening yeah and uh so i just did the uh rebase dash i you know head trick and uh so what it does show you is it does use the dot dot syntax which now i know how to read so i know it's going from the committed shows here dot dot the one here so it's back to the the one the number i specify but does not

include it uh and then if i rebase of like squash these two together it's telling me that's going to replay those onto and it gives me another hash here so the dot dot without anything after it implies head right so it was basically going from your latest commit all the way back to whatever you specified at the beginning of those dot dots, right? You did, I think you said head tilde 3 or something. Yeah, so let me try here. So I do rebase instead of head tilde 3. Let me try doing that, the dot dots. Oh, it doesn't like it. Let's see.

upstream. Yeah, well, he's doing that. Like the next two kind of drive the point home of what jay-z is saying right now is if you do like they said master here as the name of a branch if they did master dot dot that's the equivalent to master dot dot head meaning hey show me all the changes that happened since the last rebase or merge is is essentially what that one's doing and that's why he uses that one or wait, that's the wrong one.

No. When you're looking at the changes that were made in a branch since that point in time, the next one, the dot dot master, is essentially head at the beginning and then dot dot master. It's equivalent. It's useful for seeing changes since the last rebase or merge. So go ahead. Well, I'm'm sorry i didn't mean to cut you off no you're good in either way though head is going to be implied if you don't

specify one in that scenario because i was curious since he since the author called it out in his example of branch colon i'm sorry branch dot dot he called out that, you know, it was the equivalent of including head. And I was like, well, why didn't he include that same kind of, you know, call out on dot dot branch name? And at least in my example, I did a git diff where I was in some other branch and compared it to whatever the trunk branch was. And I did, you know, get diff trunk dot dot versus get diff dot dot trunk. And it literally showed me the same data.

Just, uh, you know, things were flipped around, you know, like what, in the difference being of like whether or not I've added or removed something,

you know, like, or, or if something was an addition to, I should say not add or remove, but if something was an addition to i should say not add or remove but if something was an addition versus something was a uh not really a subtraction but you know a missing you know kind of thing yeah so yeah so uh i'm still playing with the rebase here sorry uh so you know well rebase never is coming up in the next in the next chapter, by the way.

Yeah, but just in reference to like kind of how you can refer to different different commits in different ways. And the things we're discussing here. So like I've just always been in the habit of doing like get rebase dash I. And I would do like head till the I don't know, maybe 10. I would just kind of pick a number that seemed out right. And it never really occurred to me like that all the different ways I could refer to ranges here i was just like this is how you do rebases so now i know i can just pick a commit that i know is you know when i go back to you i can just pass that and it'll figure it out i'll do the dot dot head uh implicitly i can also just type in the name of a branch so if i want to

basically rebase on top of another branch which is the way i would have said that before now i'm going to share what it's doing if i do get rebase dash i and then the name of another branch, which is the way I would have said that before. Now I understand what it's doing. If I do get rebase dash I and then the name of another branch, what it's doing is saying, hey, rebase these changes going back to the commit this point to by the head of the branch I just typed. So all the things,

it's just saying the same thing. You know, like it makes me understand this from like a more of a programmatic level where all I'm doing is just passing a range of commits. And there's a bunch of different ways you can do that. And now I feel like my vocabulary with git has increased like at least double i'm

definitely gonna scrutinize your pull request a little bit more now that i know you just rebase on some randomly chosen so i'm doing interactive so i'm basically like i've got about three or four of these that i want to squash together so let me just pick 10 and i'll go and do my three or four and that's fine that's so crazy yeah well i mean what else like what if i gotta look at the log no oh dude yeah i'm gonna scrutinize yours too but then you want like you want to see a little bit around your stuff you know you don't want to just you like that you know see a little bit of before and after. You need a little buffer. Huh. I'm surprised he doesn't do like Tilt-E-30.

I mean, he commits like every five minutes or so, right? I think he's got a lot of commit. Not at work. At home, I'm switching from the couch. That's another story. I can't wait until we get to the rebate section now because it was... It's good. I will just go ahead and say the author makes a very strong opinion on why you should rebase. But he's also I appreciated how careful he was in calling out why you want to be careful to not use the situations in which you want to

be careful to not use it as we've called out in past episodes as well. So I really appreciated that. Like I thought he did a great job of walking that line of it. So, all right. So the next few, there's only actually a handful left here. The next one is dash sense, like S I N C E equals, and then in quotes two weeks ago. So it makes sense, right? Like this is going to say, Hey, show me everything that's happened since that period of time. Now I don't know what all the syntax here is. I didn't realize it was so English, but that's kind of cool. Yeah. I mean, like you can do dash sense, you know, two weeks ago or dash until two weeks, you know, one week ago or whatever. So like, again, you know, think about if you wanted to do a git diff of something or you want to like look at the log or something.

So I don't know, though, like how I've known I've known that git had this. I don't know that I've ever in my life thought, Oh, you know what? Oh, this is, I want to use that now. Now somebody else might have like a great example of like when they would want to use it, you know, like, Hey, I was on vacation and things were fine. So what changed since I've been on vacation, you know, or whatever. And then you would like know the timeframe, but I I've just always used the IDs instead of some arbitrary, but you know, time, especially when you're like, not including like clock time, you know,

and you're just using like something super fuzzy relative. Right. Yeah. That's relative like two weeks ago. Cause it's like, well, what is two weeks ago for you mean? Because like, what if like alan threw in a commit that was like you know 40 seconds before that two weeks ago cut off and now i don't see his commit as part of whatever that get operation is that i'm doing right then you change your search that's why three weeks ago yeah that's what joe would do he rebased minus i three weeks ago that's right right. I actually have an idea, though.

You said, when would you do this? I think it would actually be in conjunction with this next one, right? So I think I did something about two or three weeks ago. I can't remember what it was. I don't want to grep the entire commit log. So you could do dash grep equal and then put a pattern in. So if you did that in conjunction with your timeframe, I think that makes sense, right?

Maybe, yeah. Because I've definitely done things where I'm like, well, I know I did that like last month, and I don't really want to have to try and go find the pull request where this happened or whatever, then this would be a good way of putting in dash grep equal and then put your regex pattern. And then you're limiting it to a time frame instead of going over all your commit log.

Yeah, I remember there was like a get commit thing that I shared like way back early days of the show, like year one. And I remember some people were like, well, what would be a situation that you would use that? And I shared it, but now I was like, I've gone back and I've thought about that and I'm like, man, I would never go back. I would never look at it that way. I would never use that. I don't know what I was thinking about like 10 years ago. It's on the record now. Yeah.

Well, I guess I got to use it then. Yep. So the last few, the last few we have here are dash author equals, and then you put in the regex pattern. Um, and then dash commit or equal pattern.

And Jay-Z, you want to talk about those? Yeah. It's just a weird one. Cause the first thing I was like, okay, fine. Let's see what the,

the author is. Okay, fine. Let's see, uh, what the first thing I was like, okay, fine, let's see what the author is. Okay, fine, let's see what the committer is. Like, wait, isn't that the same thing? And the deal is if you're working locally in almost all cases nowadays, those are going to be the same where your committer and author are. But the cases where you're doing things over email, like someone sends you a patch, then that might be a case where the committer is different than the author. And so those are technically two fields yeah that one was odd yeah so someone literally like and this is like pretty specific to kind of like old linux workflows and stuff or like

some other email as a patch and you're like okay i like what you did here i'm going to take it and so i'm going to commit it but I'm going to mark you as the author. Yep. And then the last one was dash no dash merges. And that would just return you only commits that have a single parent. So you don't have the multiple parent scenario. And that was it for the commands that they shared on this one. But I think those are all really useful to understand. Like if you see that syntax now, it shouldn't make your mind explode and just be like, oh, whatever. You know, I'm going to get rebase dash head tilde five and see what happens. So think about this. So, you know, when I like figure out how to cherry pick stuff, for example, for one branch to another, like a way I used to might have done it, but basically to, you know, look at my commits, look for the ones with my, you know, branch name or ticket name or whatever the comments and kind

of gather those up and, and take them. But now I know a more precise way of doing that is now I could say, okay, uh, I guess get log. I'm still unsure about this part. So git log and then i can pass um what i want to do here the name of the other branch and then i'll have an implicit head so it'll give me all the commits that are in my current branch that are past the head of the other branch i'm looking at dash dash no merges so if i pulled in another branch or whatever i don't worry about that and that's going to give me a list of all the single commits that i should consider cherry picking over into the branch i'm looking at sounds about right yeah it's pretty cool okay so i apologize i uh went off into like you know searching for it because i wanted to go back and find it so i didn't follow all your example there but uh i found the the thing that i was talking about

the the tip that i was talking about and you know going back and look at it i'm like okay that is that is different than what they're talking about here and i went back and reread what we were talking about here with the grip pattern on you know from what the author talking about here with the grep pattern on, you know, from what the author was saying here. So, cause he's saying like, Hey, you could do like a dash grep equals some pattern to refer to all the commits whose commit message matches that pattern. Right. Which I would have immediately been like, well, why wouldn't I just do like a get log pipe that to grep, grep that out,

awk the first IDs. But by doing this dash grep equal pattern, you can avoid that. The commit that I had, or the, I'm sorry, not the commit. Well, I did commit to this in 2015. But the tip that I had from 2015 was not if you knew what your commit message was but what your content was

how do you go back and find that then if you just knew the content um so like i don't know maybe i had some special variable called foobar and i knew that that thing existed at some point in time and it's since been removed like you know what what was it and and that might be a silly example but like if you wanted to go back and find that content you know like but you know like a part of it so that's still useful yeah it's still used i still you know yeah that one's okay that was from episode two no uh sorry i put i put i'll have a link in the show notes for this but yeah it goes back to episode 31 from 2015 it's been a minute yeah you were what 14 because you're 21 now right something like that yes thank you thank you that's you know what if you're back

on the christmas card list that's right if you go back, the outlaw sounded like this. So today's get tipped. That's right. That's right. Thank you. Yeah. It's been a minute, but yeah.

So, uh, okay. So we, we, we wrapped up while I was doing the search. So then, uh, yeah,

we'll have linked to this book. Um, dang it. I forgot it already. Second letter. There you go. Oh man, nailed it. The show's over.

Let's just stop it from right there. I got 12 tips of the week. We can't do that now. I guess we'll head into Alan's favorite portion of the show. It's the tip of the week. Alright. Looks like I'm going first. I think I always go first. we'll head into Alan's favorite portion of the show. It's the tip of the week. All right. And it looks like I'm going first. I think I always go first.

So, uh, Simon from the, all the cod, uh, code podcast, which we've mentioned a few times. Uh, Simon's great.

Uh, he, uh, recommended to me super base. I was looking for a way, basically a small project I wanted to work on. And I wanted this, a simple,

uh, JavaScript solution that I could do where I could basically just work on the front end and be able to fetch simple data out of a database without having like a middle tier. Like I didn't want to have to go and create a new kind of C sharp or Java or Django service or something and get that hosted and get it updated when all I'm doing is just like simple crud into and out of the database. So I was looking at some of the things that are out there, like Firebase is the one that I probably had come to mind immediately. So I asked for help in our JavaScript channel in the Slack and got some great tips there. Also, Solomist, which I mentioned before, is recommended to Soro,

which is something I also really love, GraphQL. But the one I ended up going with and liking the best ended up being Supabase, which I got from Simon. And what Supabase is, is it's an open source alternative to Firebase that's based on Postgres instead of a NoSQL database. You got me. Yeah, it's really nice.

You can host it yourself, so you can actually run it in a container and kind of work locally or use their service, which actually has a really nice path to get to up to production so they'll actually you can click one button and it'll spin up uh postgres in heroku on the free tier i just read today that the free tier is going away so you know who knows what's going to happen that maybe it'll work something else out but it was

a great experience for free the weekend where i was basically able to get something like up and hosted and in addition to actually you know just making a really nice experience around you know getting something running on heroku uh they uh provided javascript library libraries for interacting with my database you handle all your r back and stuff through creating policies on postgres which you know when you're thinking of like if you're doing a very large huge project that's you know got a lot of really specific business logic and rules and stuff, that's probably sounding pretty scary to you. But if you just need to do a simple CRUD app, that's awesome. Because I was able to go in there and say, hey, reads for these five tables, you can do whatever you want.

Authenticated users can update, insert, and delete those tables. And they can also read data in these other tables i was able to do that in like two minutes i actually had a little wizard that would create it for you that was just postgres um policies at the end of the day so you can actually just manage it you know however you normally do your postgres stuff and so that was really great and then there's also client libraries for querying data so i was able to just in javascript be able to say you know know, it's basically a DSL. It's like select this data from this table, join that table, where this, order by that. And it read pretty close to a query.

Really good experience and the docs were all really great. And it had a really nice integration with like authorization. So you're able to do like Auth0 or Google or even username and password.'ve got a database there so they set all that up for you and it's just a really great user experience so if you're looking at doing a small project super base will get you most of the way there i did not find a way through super base.com to actually host the front end so i ended up doing that through netlify which you know i love netlify that was really great so that you know took all two seconds i had like a website set up with a custom subdomain on netlify.com with ssl set up and now whenever i commit to main it deploys to uh it deploys to netlify and i've got a database and no middle tier that there's no

middle tier that i'm managing which is nice that they if you look at the source code it's all just done through serverless stuff so they've got a really nice free tier as we've talked about before um those serverless solutions can be really cheap so as long as you're under like a you know it's like 10 billion requests per month whatever then there's a free tier for that. Otherwise, I think the first paid tier is $25 a month, which gives you to like, you know, 2 billion requests, whatever. Still not terrible.

No, not at all. Totally for it. It's crazy to me that you can do this in like two hours. You can go through and set up Postgres database serverless server side stuff. So you can just query from a front end publish for free and like somehow you don't spend a dime and you've got like a website, side stuff so you can just query from a front end publish for free and like somehow you don't spend

a dime and you've got like a website a web app but what kind of game are you writing that you were going to use a database no not a game just different project like a little crowd i know i know and it's sponsored by nicki minaj so that's right Bass. I have actually no clue to that. Oh, Super Bass. Oh, nice. Yeah. I got a cultural reference. How about that? Yeah.

All right. So, I also have a tip from Mr. Simon Barker. Apparently, he had lots of good stuff to share recently. So, we were chatting the other day on Slack, which, by the way, there's another tip. If you are not part of our Slack group, you should go join it because there's super awesome people in there like Simon and Sean and Lars, all the people that I'm going to reference here. So this one is a thing called

Obsidian. So I've got a link here. It's obsidian.md and it's pretty cool. So what it allows you to do, man, it's like, it's like this tool that you can create files on your system and they're all marked down. You make a bunch of markdown things so that you have notes or whatever. And this sort of organizes it. And it's not an IDE and a UI that allows you to look at your things. And it'll even create like this map, this graph of all your connected documents. So you can link between them. You can see how things are together. Like it's like a really nice way to organize your thoughts.

And because it's yours, you can store this wherever you want. Like if you want to put it in the cloud, you could. All you have to have is this Obsidian client and installed on whatever it you've, you can get it on iOS and get it on Android. You can get it on windows, Mac, um, Linux, uh, they have Linux snap and Linux flat pack, and they've even got more platforms. So you just need this, this gooey client wherever you're going to look at this content and you can look at all your thoughts laid out in like this really cool way. So he's been playing with that.

Um, looked really cool. So he mentioned that the other day, go check it out. I think I'm going to actually look at this one. This, this looks pretty neat. The next one. So that led Sean Martin to saying, Hey, saying, hey, this reminds me of my maps. I really like my maps. And if you've never used those tools, I love my map tools.

I like the way that it lays out things visually to show how ideas are connected. I've just always loved it. And it reminds me of things in college or when they told you like the best way to study with notes was to sort of create these mind maps on papers because it paints a picture in your head better that sticks. At any rate, this one is mindnode.com. I would go check that one out. It's also very cool. I don't know if this one's free. It's on Apple and Android, and it looks like it might be on other platforms as well. So at any rate, check that one out.

And then the last one, Lars mentioned this in regards to obsidian, because he said this reminded him of this other tool, and it's called InkDrop. So InkDrop.app, this one is interesting because while it is similar to what that obsidian is, this one's more for developers. And what's interesting about it is you do things in Markdown, very, very similar to what was in obsidian. But what's cool is you can create like task lists and whatnot.

And this, this GUI allows you to organize things and sort of like check off things as you go with this. Um, I haven't dug into this one super deep, but it looks like it's got a lot of very cool features and it's very developer oriented. So, um, things to help you as a developer do things. So, uh, three really cool tools that I recommend going and checking out. So thank you to all three of you guys for dropping those in the chat the other day. Awesome, awesome, awesome. You know what, Joe?

Just because, you know, don't feel like you're all special because you're over there making stuff in your free time because I also make stuff in my free time too. Oh, yeah, Tom? Yeah. I made a belt out of watches once it was time to do it no but it did turn out to be a waste of time oh that's very nice um okay so how about this one we're talking about git and have you ever had this experience happen to you where you set up your new environment or like WSL instances where it happened to bite me? And you like all like certain commands like get log, get commit, whatever.

Whenever you do it, it like brings up, you know, full screen like you just lost all your terminal space for it to see the log. And then and then it's like, do you want to quit? And you quit it and you get out to get out of it. And now you can't see what that thing was anymore. Right. Yes. Super annoying. And it's actually not necessarily like a get thing exactly, except the pager that Git uses for it. So I'll have two commands in here, one where you can

change your Git config to replace the pager. Or what I did, which impacts more than just Git, is if you change the variables that are the export less. You'll export a environment variable called less, and you're going to default some, uh, variables, lowercase I, and then the other three are going to be uppercase X F R. And what that'll do is, uh, when you, um, do when, when less as used as your pager, it'll not clear your screen when when you exit. It will not clear the screen if there's less than one screen of text. So, you know, you use that. And then there's the I think the R was for colors and the I was to ignore case. But anyway, I wasn't sure

like why I needed the I, but this is one of those examples where you like just copy and paste and you're like, Oh, where's all over here. But, um, but I'll have a link to the article where, where I got it. Cause I loved this guy's the, his blog was, uh, them get AWS and other three letter words. And I was like, Oh, that's so great. So at any rate, uh, we'll have a, we'll have a link to that. And then you can, uh, you know, use get like a normal person without having everything like disappear when you're like, yeah, but I wanted to see, I did a get log for three, you know, five, 10 commits. And now that I quit, I, you know, the, the output of log, I no longer see the log anymore. That doesn't do me any good. So yeah. Um, all right. So I'm

going to keep it simple. That was just my one tip. How's that one tip and done. Yeah. I didn't have like 18, like Alan, Mr. Show off. Cheating. So, yeah. So subscribe to us on iTunes, Spotify, Stitcher, wherever you like to find your podcast app. No, not your app, but the podcast. And like I said earlier, we would greatly appreciate it if you would leave us a review.

If you hadn't already, you can find some helpful links. I'm going to say it right this time. www.codingblocks.net slash review. Hey, and while you're at www.codingblocks.net, you can check out our show notes, examples, discussions, and more. And you can send your feedbacks, questions, and rant to our site channel. I'm surprised you didn't go the extra mile and go like www.codingblocks.net slash codingblocks. I was going to mess it up if I did that.

Yeah, okay. Alright, and hey, we got Twitter at CodingBlocks, and if you take a picture of your battle station and tweet it at us, we'll be impressed by it. Also, go to CodingBlocks.net and find other social links at the top of the page, including ones to

join the Slack, for example. So, hit us up.