Coding Blocks - Git from the Bottom Up – Reset, Stash, and Reflog
Episode Date: October 10, 2022We wrap up Git from the Bottom Up by John Wiegley while Joe has a convenient excuse, Allen gets thrown under the bus, and Michael somehow made it worse....
Transcript
Discussion (0)
You're listening to Coding Blocks, episode 195.
Subscribe to us on iTunes, Stitcher, Spotify, wherever you like to find your podcasts.
Visit us at codingblocks.net, where you can find the show notes, examples, discussion,
more.
And send your feedback, questions, and rants to comsatcodingblocks.net, and follow us on
Twitter at codingblocks, or head head to coding blocks.net and find our
social links at the top of the page with that i'm joe zach i'm alan underwood oh it's not the same
oh it's not dang it i thought i did a pretty good out on there it was pretty good though oh thank
you thank you and i'm michael outlaw oh and by the way, we should mention too, you forgot when you gave out the website,
the www.codingblocks.net or period.
I always forget that period.
Yeah.
Codingblocks.net and it's all lowercase.
Yeah.
You're right.
You're right.
This is what it's like without Alan, though, by the way.
So just to let you know, if you want to just skip this episode, we're telling you ahead of time, Alan's not here.
He's not going to sneak in midway.
He's really not here for this one.
This episode is sponsored by Retool.
Stop wrestling with UI libraries, hacking together data sources, and figuring out access controls.
And instead, start shipping apps that move your business forward.
Okay. trolls and instead start shipping apps that move your business forward okay so uh yeah we're gonna clearly you didn't get my cobra kai reference there so you must not have watched that um i
just finished it i just finished the latest season how did you not get my reference then earlier just
like a moment ago i don't remember okay well
now i'm well now i'm watching it was from season two when he was like learning to I don't remember. Okay. Well,
now I'm,
well,
now I'm watching it.
It was from season two when he was like learning to,
when Johnny was learning to use the computer,
he was learning.
Yeah.
And it,
well,
I know,
I think it was before that though. He,
he was trying to spread the word about it.
And so he's handing out flyers and he like goes up to some kids and hands
him a flyer.
And he's like,
yeah,
just go.
It's like yeah just go it's like
www.cobrakai.com and it's all lowercase or something like that i don't remember what the
url was but it's something like that yeah nice yeah yeah i love that show so good i have a shirt
even a cobra kai shirt yeah why would you have a shirt for the enemy? I mean, I can't say that cause I have Decepticon shirt.
So I guess,
well,
if they had Eagle Fang shirts when I bought out,
we got one of those instead.
Eagle.
What'd you say?
Eagle Fang.
Oh,
you were clearly not caught up.
I'm not going to spoil it for you.
You got to finish watching them.
Okay.
Oh,
Oh,
I should have led with that.
No,
I haven't finished.
Okay.
Yeah.
Yeah.
Eagle Fang is the best. Eagle Fang is the best. Well, uh, all right. Well, I should have led with that. No, I haven't finished. Okay. Yeah. Yeah. Eagle Fang is the best.
Eagle Fang is the best.
Well, all right.
Well, I tell you what.
Get out your favorite terminal and go ahead and CD into your favorite Git repo because we are going to be messing some stuff up tonight on this episode.
Actually, you probably want to pick a repo you don't care about.
Yes. episode. Actually, you probably want to pick a repo you don't care about. Um, but so we're going
to be talking about all the things that you can do with get reset. Uh, maybe you don't want to do
on a repo that you actually care about at any rate. Um, yeah. So first, how about we get some
thanks to all the reviews that we got from last time since the last episode.
So big thank you to – let me see if I can get these right now.
Jesset Sylvia, Marco Fernando, and SysadMike702.
That's why I like the SysadMike.
It looks like Sysad.
Yeah, good.
You did an excellent job reading
got them all perfect oh thank you yeah i also i i kind of thought when i thought of the when i read
the sysad mic it made me think of uh beastie boys oh yeah nice oh yeah yeah yeah well speaking of
all i i thought i'd be telling you about my ludum Dare entry right now, but I couldn't do it.
This whole thing called Hurricane Ian came through, knocked out my power, knocked out my internet, knocked over a bunch of trees.
So, yeah, I did not make a game.
It's unfortunate.
So now I'm going to try and find some other jam to do in the future.
I don't know.
But, yeah, I didn't do it.
All right.
So if you think that that sounds like a convenient excuse, just write in
the comments. This will be codingblocks.net slash episode 195. All right. Excellent.
So we are on with the show. We're actually going to finish the book tonight.
The quote book. Yeah. I forgot the name of the title or else I would have said it. It's called Get From The Bottom Up. And the author,
if I can say this right, is John
Veigley. And Alan's not here to tell me I got it wrong, so
of course I got it right.
Because I'm sure it's not pronounced perfectly. You can also find a link
and the words themselves in the show notes and it's
open source books that can go contribute,
read it all for free.
So it's good stuff.
Well,
that's why I was like quoting like air quoting like book because like,
do we still call it a book if it's on the internet?
You know,
it's like a webpage that at that point,
like,
I don't know.
I mean,
the crazy thing is,
is that I have found today there are like other people have copies of this book as like, here's the PDF that you can download it from. And what's even crazier is that those PDFs are also hosted on GitHub.
Oh, nice. So if you haven't already looked at this air quote book that John put out for the world,
Git from the bottom up, it is hosted on GitHub.
So that's why it was kind of weird that there were other references on GitHub.
Yeah, really good.
Yeah, yeah, it is.
It is really good.
So yeah, let's talk about Git reset.
Yep.
So Git reset is one of the commands that people are often kind of scared of because it's the one thing that can really kind of mess you up really bad if it goes sideways.
There's three different things that it can mess with.
In fact, three different things you can touch.
And the book refers to them as it being a reference editor, an index editor, and a working tree editor.
And just to kind of take that backwards because some of the terms are a little awkward.
Working tree, remember, just refers to like your local director where you're actually doing your work, where you're changing your files.
It's like the place where you spend your time.
It's your files.
So git reset can change your files it can also change
the index which you remember that's uh where you um the file that's used behind the scenes to
actually stage your changes before you commit them and then the reference editor really threw
me off there but really what it's talking about is that head file so don't let that trip you up
like it tripped me up,
took me a minute.
And,
uh,
this is kind of a side note there where I was kind of messing around,
uh,
reading through the chapter and kind of doing some things.
Uh,
I noticed at one point that my head file wasn't getting,
uh,
updated.
And,
uh,
it's because I had entered a detached state,
uh,
detached head state at some point.
And another file got added called a ridge
underscore head have you ever seen that
no
yeah so I didn't track it down to like you know
work too hard to figure out where it came from and what happened there
but what I figured out is basically whenever I was
you know doing changes expecting head to be modified
it was actually making the changes over in
a ridge underscore head
huh
it's kind of interesting.
There's still things that I don't know about Git.
Quite a lot, actually.
This book is definitely the basics.
There's a million flags we're not
covering. Different verbs
we're not covering. Just tons of stuff.
I think I mentioned something like this
in one of the recent episodes.
We've been using Git.
The three of us have been using Git
for well over a decade.
And,
you know,
there's still,
like,
I thought that I had a pretty good handle on it.
And then we started this series
and now I feel like I've gotten a much stronger handle on it.
Yeah.
Oh yeah,
definitely.
I wish I did this 10 years ago.
Yeah,
we'll have to write a sternly worded letter to John.
Why did you?
It's your fault, John.
He and I are on a first name basis, by the way.
Me from 10 years ago in another timeline gets a visit, you know, book drops out of the sky or like a gift from the bottom up.
Thanks, future Joe.
This is the one thing like why not a sports uh
you know sports almanac so so let's start with before we get into this like do you use reset
often yeah pretty often um my the main thing i do with it though is sometimes when i just want to make sure i'm absolutely uh you know in sync i'm doing uh
in line with uh the my origin i'll do a reset hard uh origin slash you know main and that's
what i'm saying basically okay i've you know i'm done whatever whatever i was working on is done
merged i'm you know going back to um working off of you know branch of creating a new branch off of my main, my trunk.
And I just want to make sure that I didn't accidentally check something in somewhere along the lines and I'm just totally trued up.
Man, that's a crazy one.
I didn't expect that.
No.
But okay.
I mean, I'll take it.
Sure. I have a lot of expect that. No. But okay. I mean, I'll take it. Sure.
I have a lot of scripts that do stuff for me too.
Sometimes I'll have it like, you know, check out a branch, do this, do that,
you know, pull in whatever.
And so like one of the things I've just gotten the habit of doing is always
resetting main before I check out just in like,
I don't even remember the last time I've accidentally checked something into my
local copy of main or trunk.
But it's stuff that happened before and can get kind of weird.
Huh.
So I was thinking of, and I shared this as a tip of the week back.
I don't know.
It was episode 114, where more often than not not like if i want to do it it's because
i made a commit and then i'm like oh wait i need to undo that that commit and like fix something
about it and so uh you know i i had a uh reference to a stack overflow article that i always like
to this day like like I always double
check myself because I'm like, wait a minute, I want to make sure that this is the right command
and I'll go and look at that and be like, yep. Okay. I feel, I feel good to proceed.
And you know, so yeah. So, so when I do the get reset more often than not, it has been
because I want to like undo that last command. What command would you do i'm sorry last commit sorry
last commit you know is it like a soft reset or uh um amend well okay so we can get into this
um you i i would typically do the what would be the default. So I wouldn't specify, uh, any other flags to the reset
command, which defaults to mixed, which is a great segue into let's talk about the mixed
parameter. Yep. So, uh, this is like, so if you were to do, let's say you wanted to undo the last commit.
You want to roll back the commit by one.
Then if you do a git space reset space minus minus mixed,
and I'm not going to bother with the spaces anymore,
and then you did a head caret,
then you can go back.
You can revert your,
man, I hate to use the word revert
because I don't want to get terminology here,
but you can roll back your state back to the previous head
and it will, what was in that previous commit
will now be put back into your working tree. So all of the files that were changed
in that previous commit that you're kind of like rolling back will now be put back in your working
tree as files that have not yet been or changes that have not yet been staged to the index.
Right.
Now, that's how I put it into words.
How would you put it into words?
Yeah, I think that's pretty good.
It's tough to get it exactly right.
And it's very important when you're working with, you know, changing files in your index and your working tree and your head that you know exactly what you're doing what's funny though is that if you had asked me before uh reading this section what i thought would happen if i did a get reset without passing uh hard or soft and you asked me what it did i would have guessed that it was doing a soft and i just never really thought about it
too much i don't know if i ever even did it reset without passing a harder soft before um well yeah
this is again where i was victim of like, where I've talked about,
you kind of become a creature of habit and you don't go back and look to see like, Hey, what,
what are all the options or, you know, and things like that. And you're like, okay, I know that
these are the ones that are like, you know, this is my path. This gets me to where I need to be.
Right. So I never even realized that there was a dash dash mixed and it, but it is the default.
And the reason why I would use that is because going back to what my use case was, if you
think about it, it would make sense.
Um, because my use case was that I wanted to change something about that commit.
I wanted to like, you know, undo something like maybe I didn't mean to check something in, then resetting head to go, you
know, to point it back to the prior, to the commit prior.
And then, um, also, uh, putting those changes as, um, back into the working tree.
So they aren't staged allows me to then selectively go back and put into the, to stage back into the working tree so they aren't staged allows me to then selectively go back and put
into the, to stage back into the index, those changes that I did want or that I did mean to
have in there. Right. So it makes sense why like that default worked for me and I never bothered
to care any further. Right. And also too, we should point out, you know, like in the previous, in that episode 114 that are referenced, in there, I was using tilde.
But in the example that I just gave, I said caret, which caret would be the parent commit.
So you're saying the parent of whatever head is, right? If we go back to our name terminology
and I'm trying to remember the name terminology for
what the tilde would be. Oh, yeah.
Do you remember? Was it a range?
No, I don't remember. I don't either. I'm going to go back
and find it real quick because here it is so if you did the tilde uh well maybe this wasn't gonna be as quick as i
thought i thought we covered it in episode whatever this is episode 192 when we talked
about the git commits but i'm not seeing it there. Let's see.
I also thought I was going to guess, I guess 194.
It's the number of carets, and so I guess the one is default.
We did kind of cover it, but we said name tilde 10 in the example.
Yeah.
So we were saying like the 10 commits.
Yeah, I do that all the time. Yeah. I love that one. So we were saying like the 10 commits.
Yeah, I do that all the time.
Yeah.
I love that one. I know yours is 20 commits, though, when you do your rebase.
So we know not to trust your PRs.
Yeah.
That's a lot.
Yeah.
So let's say this again.
What all was happening in that reset mixed command, right? So we,
we basically did some multiple things at one time,
right?
One,
we updated head to a new ref,
which I think the author called it out as like a separate,
uh,
command that you could technically do,
like get update ref head.
And then you were,
you're telling it what the new commit is
which in this case we're doing head carrot so uh get update dash ref head head carrot so heads in
there twice i don't i'm trying to be extra clear on that but um that's one of the things that's
happening right yep then the other thing that's happening is all of your changes are just being added to your working tree.
Well, so adding to the working tree. Yes. So it's going to show up as if there are new changes.
But also the last thing is your index is going to get replaced with the changes.
So it's going to basically show up as if those changes that you had initially committed are going to now be staged.
And anything that you previously had in that index, things that you had added but not yet committed, those are going to be gone.
Wait, really? No.
Yeah, it replaces the changes in your existing index with the reset commits.
Let's try it.
So you're saying if I...
I have been wrong before, even earlier tonight,
you're saying that if I have a change staged already,
and then I do a get reset dash dash mixed head carrot,
right?
Yep.
That that's going to like roll the changes.
It's going to undo whatever I had staged in the index.
That's going to be now gone.
And the other changes will be,
Oh wait,
you let me do,
let me just make sure what the state was of that file,
that example file.
Okay.
So tricky to get it right.
So here we go again.
So I'm going to do that.
And now I do my status and And then I cat that file.
And sure enough.
So you're partially correct.
Or unless I misunderstood you.
It did unstage the change from my index.
Yes.
So now all of the changes are only in the working tree.
Yes. So now all of the changes are only in the working tree. Yes.
But the most recent change to one of my files remained.
It's just now that it's in the working tree rather than the index.
Does that make sense?
Yeah, and it's not in the index.
So all the other changes from your working tree that're put in there by the get reset mixed.
You know, I forgot.
I, I, so I can't believe I'm ashamed that I forgot this when I was asking you about like, do you use get reset?
And we were talking about like more often than not, like when you use it, why you use it.
I forgot the number one reason to like, uh, why you might use it.
What's that?
So if you,
if you were to get at a file,
uh,
yeah.
If you wanted to undo that,
get ad,
you can get reset it.
Right.
Yeah.
I do that occasionally.
I tend to do that in UI though.
It's just so easy to do the,
the minus sign like VS code or whatever.
Say like,
I don't want to stay just one yet.
It's not ready.
Yeah.
So,
but that's without using any,
uh,
other,
you know,
parameter,
any other options on it.
Right.
Just,
I'm just doing a get reset in the file name.
And the thing that's super scary about that is it sounds,
it sounds way more destructive than it is.
It's almost like you sometimes wish that Git, when it was being made, some of the commands were maybe more, I don't know, explanatory about what was actually happening.
Like, you know, maybe like instead of a Git add, it'd be like Git stage, Git unstage, right?
You know, but then if you did that, you'd probably have this like vocabulary of commands
that would be like so long that nobody would ever remember it
because it would be like Webster's Dictionary, forget.
Right.
And instead, that's why we have these
commands that are like
this. Because also, you
think too,
I'm kind of off topic
here, but it almost
sounds too like if you
said, hey, I want to undo the changes
of this file, right? It sounds
like reset would be the way that
you would want to go right yes that was my understanding so here's a but but you would
do a get checkout minus minus on that file yeah that's that's the terminology i mentioned before
like the it's weird, right? Yeah.
It's not really designed for human beings in this planet, at least.
Yeah, that especially tricked me out in the beginning when I was first trying to learn Git.
Yeah.
Yeah, I hope that one day somebody makes a Git 2 and just kind of makes it a little bit uh i don't know more consistent maybe you
know i'm happy with the way it works and the results i get but uh it's some of these things
like that it's just confusing you know you just have to memorize it well i mean not to not to
skip ahead but i'm gonna skip ahead because um you know as part of the wrap-up of the book the
author was talking about how, you know,
some of these things that are,
that are difficult like that are,
you know,
probably here for a long while because of tool chains that depend on their
current functionality.
And if they were to change it to be more like what we might think that it
should be, that it should be
that it would break all of those and you know there might be countless numbers of those so
yeah that's the depressing part yeah i got a pop quiz for you can you shoot the hostage
there were different pop quiz oh is it possible to get a conflict due to a mixed reset i tried i i i
i i don't know i also tried i tried and i couldn't generate a conflict yep and so my uh my
understanding is is that's because of uh the stage file the index changes so you lose any changes
that you have uh that are already in there and so what happens then is if you did for example
the commit that you're resetting let's say you're just resetting one you made a change to a file
now your working directory and your working tree has another change to that file and you do the
reset what's going to happen is the change to the most
recent state of your working tree is going to be preserved it's going to be there and it's going to
show as outstanding when you do a get status but the contents of that file that were in the commit
are going to be staged they ever seen that case what happens where basically um
you stage a file then you make additional changes to it and you see it when you do get status you
see it as both staged and outstanding yeah but that's not going to happen with the mixed
with dash dash mixed now if we skip ahead to dash dash soft soft, that's going to be a primary difference there between soft and mixed resets.
Is that when you get reset dash dash soft head caret, let's use the same example that we did for mixed.
In that case, it'll roll back head just like it did before to the parent commit of what was head. And then the changes from
that commit that you're rolling back from, those files, those changes will still be there in the
repo. They will be staged in the index as changes to be committed.
So in other words, if you did some, you, you change two files,
you add them, you get commit. And then you're like, Oh,
I want to undo that. So you get reset dash dash soft head carrot.
And then you're like, no, I'm good. And you get commit it.
Those two commits that you did would basically be the same thing because like the files were already staged after you did that that reset whereas in the mixed example they are not staged so what i'm doing here is i've added a new file
called hello world and i've not committed it yet so if i do a git status i see the item has
been added it's to be committed now if i go into this file hello world.txt and i change it and do
a git status right i see the file is being uh changed to be committed and i also see it not
staged for commit it It's listed twice.
Yeah.
Okay.
I've definitely seen that example,
but I thought you were saying that in the get reset mixed,
that it would leave one of the changes in the,
the index.
So I'm about to find that I was just setting the stage.
I just wanted to make sure that,
you know,
we kind of set that case.
So now I've committed,
I went ahead and, you know, added the second change so basically i've you know got hello world
checked in here so now uh what i want to do is make a change this so i'm going to say i don't
know good night world right and i save it so now i do a get status and i've got the file modified
it's not staged i'm going to add it so i'm adding the file
with the new contents of good night world and if i do i get status i've got it uh staged so and now
you're going to do a reset mixed mixed and what my guess is going to be before you say this my
what i'm saying is going to happen is that the the head will roll back and the changes from whatever that current
commit were are going to be put into the working tree along with the goodnight world change
that you had staged in your index.
I think I did something wrong.
Because that's the exact example that i did
and i was trying to generate when i was doing it i was trying to generate a conflict to see like
what would happen and instead i just saw that my results were getting merged
like or or at least the current state of the file was whatever the whatever my last state of the
file was i guess would be a better way to say that rather than merged yeah i think i must have goofed something
because uh what happened was almost what i expected so what happened is the contents
are still say good night world yes it's not committed but it's in the working tree it's
in the working tree yes but i don't have anything in the index but i expected to have it in the
index no no no am I getting confused again?
I'm getting confused with soft.
This is exactly the scenario that I was trying to describe.
There would be nothing.
Because you did a dash dash mixed, nothing will be in the index.
And the change to your file will be put back into the working tree along with any other changes that that commit that you're undoing, essentially.
You're the one you're rolling back from whatever other changes were in there. So like if you had, I think you had two files, right?
In that, in that commit. So you should see the one change with your goodnight world and then
the other file, both in the working tree. Yes. Okay. Yeah. And that's because you did the dash dash mixed.
Yeah.
I just expected to have it staged as well.
No,
that's the thing is that the mixed,
the mixed takes,
you know,
the mixed,
what we're learning is it,
it takes things out of your,
uh,
it puts everything into the working tree,
even things that were in your index.
Right.
So it takes whatever that commit is,
whatever the commits that you're like rolling back from and the
index,
it puts it all into the working tree.
Now,
what happens if you were to do like multiple?
Yeah,
it combines them all back into the working tree. Yeah. All multiple? Yeah, it combines them.
All back into the working tree.
Yeah, all back into the working tree.
Yeah, I keep saying that.
I need to not say that.
I know.
It's like this is another example of like where the choice of words.
I would not.
I don't know that I would have chosen the word index to represent the staged area, you know, like
stage would have been great. Great word for it. I, I, I, I'm a fan, but yeah. So I get,
I get that one confused too. That one, that one mixed me up. So I have to like force myself
to say it so that I can like not get confused by it. Yeah. So the changes,
so,
so you,
you do the reset dash dash mixed changes.
Any changes in your index are put back into the working tree,
including those changes.
So is this changes or.
Yeah.
Okay.
Yeah.
Yeah.
Yeah. We had that. Yeah, yeah.
We had that right in the notes.
I was just trying to read over the notes.
So, yeah.
And if you did more than one, like I said, they would all be...
The changes would all be staged...
Let me not say staged.
They would all be put back together into the working tree.
I'm updating the notes right now to make it worded very specifically.
Yeah. Yeah, I'm going to really scrut now to make it worded very specifically. Yeah.
Yeah.
I'm going to like really scrutinize the wording on these.
So,
uh,
you know,
by the time you're listening to this,
you can follow along with the show notes and,
uh,
you know,
go from there.
But,
okay.
So we kind of already like hit on the reset though,
or the soft reset.
Sorry.
Yeah.
Um,
so it will,
it will take the contents of the commits that you're rolling back from
and put them into the index.
So they are staged in the index at that point,
which I think our note here is wrong because, yeah. Yeah, our note here is wrong. yeah yeah our command
our nets here is wrong so
let me
check on that
Alan did this line by the way
way to throw him under the bus
yeah
anything that's wrong that said tonight clearly uh would have to be alan's fault because
he's not here to say otherwise so yeah i can get behind that yeah sure
oh looking at the book though i see where i came from so i'm just uh sorry sorry listener i'm
reading very carefully because i don't want to
be any more confusing than i normally am uh so if we do a get reset soft head uh carrot so we're
rolling back one are you talking about that first paragraph is that what you're looking at
uh there's an example uh of doing a soft reset and there's a comment to the right of the example that says almost exactly what we have in the notes.
So I'm trying to understand what the disconnect is.
No, no, no.
I was looking at the line above, though.
Oh, I wrote that one.
Yeah, because that's the one that i'm
saying okay yeah that's definitely wrong yeah i mean yeah just yeah just look at the history okay
yeah okay because soft does touch the index is the point here yes uh that's uh so like i said
if you get reset soft and we'll just use head caret as an example,
the changes that were in current head would be reset back to the be staged in the index for the next commit.
Yep.
Yeah, and I uh sorry about that so this is um we mentioned doing some experimenting before
we recorded and this is one of the things that i was corrected on before the show started but i
did not up to date the notes i'm just going to delete that line so so both this example and the
dash dash mix i mean these are both kind of similar in spirit to that tip of the week that I
had in 14. The difference being that the soft will stage them for you. So if you were trying
to undo your last commit and you have like a hundred files and you're like, oh man, there was
like one file that I didn't mean to include, then it might be more advantageous to you to do the dash dash soft so that you can
then just unstage from the index the one single file versus if you're just working with like small
kind of commits and you had like two files, for example, and you only meant to commit one of them
and you're like, oh, let me undo it. You do a get reset dash dash mixed.
You know, at that point, you know, it's going to it's going to put it back in the working tree.
So adding the single file or using dash dash soft and then removing the single file is either way.
It's the same.
You know, what's the expression like half dozen one?
Whatever.
So then you break the eggs.
Yeah.
I think that's the, I think that's it.
You get omelets in a basket, uh, two broken eggs in a hand.
It's worth one in the pan.
That's yeah.
I'm so close.
Uh, but yeah.
So you got it right.
Yeah.
I think I got it.
Yeah.
But, uh, this is where like the author also made their
point though of like you know using this this reset command is doing the multiple things one
of them being the equivalent of that get update dash ref command yeah so so my shorthand for kind
of remembering this is that um and this is you know know, rough shorthand, but basically a mixed reset reminds me the most, you know,
the closest thing I can compare it to is like a squash
where whatever commits I take is going to take them
and it's going to queue up that squash for me.
It's not the same as a squash,
but it basically gets the things on my working directory to a spot
just to where I could go ahead and kind of commit everything
and it's going to push all those changes together
into a single commit if i just kind of you know add them and commit them together the soft reset
to me is more like the get commit uh amend where it's going to allow me to make changes
to those commits but it gets you know it's not a great analogy for various reasons but
that's the best way i can kind of think of it. I don't like that analogy because in either way, if – I mean, I understand where you're coming at it from the squash perspective.
Because you're saying like, well, what if I did a git reset minus mixed head caret 10 or head tilde 10, whichever, right?
Because you want to go back, like you wanted to undo
multiple commits in that example, but yeah, it's got me queued up to do a commit. Then that's going
to take the changes from all 10 of those commits and push them into one commit together. But in
either way though, you're the only difference here is whether or not mixed is going to put it into
the working tree versus soft is going to put it into the index. But what I really question too, though, let me see,
is would you actually get both of those things? So let's do this. So I'm going to make a commit And then I will say this is some kind of test.
And then those cherry reds.
Oh, man.
These are blues.
I hate them.
The blues.
OK, they're too quiet.
And it's red.
Yeah.
Need the reds.
So I'm going to like do another commit.
So test 18 billion.
Just in case it doesn't come through on the podcast audio,
I'll go ahead and I'll just click,
click,
click,
click,
click,
click,
click,
click.
Now it'll come through.
That's what it sounds like.
So,
so what,
so I added a brain.
So basically what I did was I added a one commit that added two new files to my repo, and then I added another new commit that adds another file to my repo.
So I'm going to roll back to two parents before those three files existed and see if all three get added back. And I don't think
it matters, but which I do soft or mixed. You got a, you got a preference. Oh, it's too soft.
Soft. It is, uh, get reset dash dash soft head carrot, and we'll roll back to, and boom. Oh, uh, I guess I'm sorry. I need to, cause, oh yeah,
that would be carrot two would be something else. If we go back to our named commits, uh,
carrot two would be if the, if the current head had multiple parents. So what I meant to do was tilde two. This is where tilde versus carrot matters.
Yeah.
Jeez.
I think,
uh,
I'm,
I hope that I said the right thing wherever else I said it in this episode.
Yeah.
I pretty much always do tilde even for,
I don't do like head carrot.
You know,
typically I always type head tilde one.
I know it's more characters,
but I just, I'm always in the habit of using the tilde.
So it did effectively, it would be the same as it rolling back both of them.
I now have all three files that were all brand new to their respective commit.
And now staged in my index.
So now if I were to make a new commit, it would be as if I had introduced
all three at the same exact time. So, so going back to your squash analogy, whether it be a soft
or a mixed, you could, you could simulate that functionality, right? Without doing the,
the interactive rebase that we talked about before.
Yeah.
I was just thinking that you remember like a,
you know,
comp sci one-on-one where like you would get a test or an exam pop quiz and
you would have to like trace the code and it'd be like,
what are the values of a,
B and C now at the end,
it'd be,
you know,
lexical scoping and it'd be all about,
you know,
figuring out how that works.
Like that's old school.
We don't need that anymore.
Now we need a test.
That's like, here are the
Git commands that are going to run on this ref
log and this
Git log here. What's the final
result of this file?
It's crazy, though, too.
In those
more advanced schools and
classes, I'm sure
they're probably, and rightfully so,
stuck more into the theory of
stuff than yeah the practicality of like here's how you use git because you know why why shouldn't
they should they should care more about the uh more of the theory stuff right yeah i guess so
but i've definitely uh helped people or not maybe not helping but i definitely
see more
get problems that I do problems with lexical scoping.
Yeah.
I mean, that, that's the, that's the reality of the, of the work environment there.
Right.
We're like, you know, the, the old, my, the old joke that I've told many times about,
like, you know, you go to the job interview and it's like some insane problem, you know, and then you get your first day on the job and it's like, okay, we need you to move the logo three pixels to the left.
Yeah.
Right.
Oh, I have a joke for you.
Oh, here we go.
It's joke time.
Don't buy flowers at a monastery.
Maybe I should ask why shouldn't you buy flowers
at a monastery?
Because Jay-Z just told me not to.
Well, I thought you were going to get it there for a minute.
Because only you could prevent
florist friars.
That's
Micah G. Thank you, Micah.
Okay.
That was a good one.
Well,
okay, since we're in this kind of humorous mood, okay. That was a good one. Well, uh, okay.
Since,
since we're,
since we're in this kind of humorous mood,
uh,
do you have any new restaurants around you?
Uh,
actually no,
no,
no.
We,
we just got a new one called karma.
Oh yeah.
Yeah.
It's,
it's,
it's interesting though.
There's no menu.
You just get what you deserve.
Oh,
nice.
Okay.
All right. Well, it. Okay. Alright, well,
these jokes can't get any better than that.
So, yeah.
You came to the wrong place for good jokes.
I just think I should never go there.
Karma?
Yeah.
What are we learning about Joe?
I've been dodging karma for years.
Keep it going.
Okay.
Well, all right.
So I think we've already covered this one about the,
if you did the get status that you'd basically see it in your,
if you did this dash dash soft, you would see them in your index.
What does this say?
I think this is wrong, too.
We got our notes wrong.
I'll have to fix this and scrutinize it.
Yeah, we should probably just not even look at them.
Yeah.
But yeah, so I guess this was your point, though.
Maybe this was another Joe comment about if you wanted to cheat the system and do your own squash manually.
Is that maybe what you were getting at here?
I'm assuming you added this.
I don't know if I did or not.
I don't think I did.
Okay.
Yeah.
Just kidding.
No more notes.
Yeah.
No.
It's so nice.
I wish I could see.
If we had the time machine that we'd use to drop this
book off in the past i would also go to the future and look at our show notes that after they're
fixed up but there's another thing here though that i think is wrong right is that uh which
line are you on right here one the yeah the the one about the amend i think that's wrong there
right because that's for the message.
So it is for the message, but this is another way you can do that
where you can basically do a reset soft head total one or head care,
and that's going to basically take back your changes,
and it's going to add them into the index file,
and you can, you know,
do another commit at this point and,
you know,
type in a new message.
So it's a way of allowing you to redo the message,
but it also lets you lump in any other changes that you might have staged.
Huh?
I guess I never had to do a,
an amend.
I thought that that was just to redo your,
your commit message.
But yeah,
in the Git documentation, they actually show it as being the equivalent
of a git reset dash dash soft head caret
and then a new commit.
Okay, yeah.
With some commands like, you know,
ellipsis in between.
Yeah, I didn't realize,
I never thought of doing a reset for this.
I always just did git commit amend,
like if I missed a file or something, you know,
then that would be my typical way of doing that
or, of course, fixing the message.
But now I've gotten to the habit of just always doing
interactive rebase, so I'll fix my messages there.
I think it's an easier way to do it.
Yeah, interesting.
Okay.
Well, I learned something new cause I did not realize that.
Uh, I should probably add a link to the one 14 and I will do that. Um, yeah. So what was this one? As previously mentioned, if you had other consumers, Oh, so if you have, if you're going to do the, either of these commands, the reset mixed or the reset soft,
uh, regardless of how many commits you're going back, if the commit or commits that you're trying
to go back have already been shared with others, you need to be careful, right? Because this is,
this is the same argument that we had for like rebasing, for example,
like the generally speaking, the rule of thumb is if the history has been shared, don't change
it.
Right.
Yep.
Yeah.
Fair enough.
All right.
So then here's where it gets worse. So we've talked about dash dash mixed. We've talked about dash dash soft. And then there's dash dash hard. of them this one can have well we say in here that it can have the most consequential like it'd be
the most consequential of the commands but like really asterisk right because if you really got
yourself into trouble and like like maybe you did a a get reset soft and you i'm sorry you did a
reset hard but you meant to do a soft,
right?
Yeah.
You can technically still go back to the ref log and,
and get back to where you need to be.
Right.
So that ref log is definitely your savior for,
uh,
you know,
getting you back into a state that you want to be in,
in,
in reading.
It can take some practice admittedly. Yeah. It's not a spot you want to be in in reading it can take some practice admittedly yeah it's not a spot
you want to be in for sure yeah but but let's talk about now why why is it so consequential
compared to the others and the reason is that when you do that get reset uh hard so let's go with our, keep with our head carrot. Not only are you rolling back the commit,
but you're also throwing away in quotes, throwing away your changes. So those changes
from the commit that you're rolling or commits that you're rolling back from are neither going to be in your staged indexed nor in your working tree they're just you've decided i don't like
those at all and that's why i'm storing the previous you know the state of the files in
your working directory to what they were at the time of that commit yeah and again that's why i'm
trying to be like careful about like you know because technically they are still blobs in the repo.
You can go back to the ref log to get back to get back to it if you needed to.
Right.
So, you know, all is not entirely lost, at least not for not until garbage collection happens.
Right. So from the moment you do that, get reset dash,
dash hard head, uh, you know, you've started a counter at that point. Right. So, um,
yeah, I think I already said that part. So, yeah. So, um, what do we have here?
Check out, we'll work similar to the reset hard.
There's nothing in the index,
meaning it'll change the working tree to what's in head.
And I think I already said all this.
Yep.
Yeah.
Um,
sorry,
I'm trying to catch up.
Yeah.
So the next part is good.
Uh,
you're going to like this and,
I'm learning to like it.
So,
uh,
the author has a suggestion for what to do when you're, uh, and uh i'm learning to like it so uh the author
has a suggestion for what to do when you're uh doing a hard reset and even though we said we
can restore changes from the ref log uh the author recommends doing a git stash uh before you do your
reset um specifically uh an example we didn't mention, but basically, um, you're going to say something.
Well, no, I think, I think this is assuming though that you had staged changes.
Let me rephrase that.
Um, you have changes that you haven't committed yet.
And before you do a reset, you want to preserve those changes, but not commit them.
And so his answer to that was to do a get stash followed by a checkout command. And the checkout
command is going to go like this, get checkout dash B, and then give whatever your new branch name is,
and then head tilde, the number of commits you wanted to undo. So, uh, just tilde,
if you only wanted to undo one, but you know, if you wanted to undo some number, then you could,
um, specify that number or again, use the, the carrot carrot if you wanted to go to the parent commit of head.
The point is that you're creating a new branch that goes back to whatever the previous commit
is that you wanted to do. And the point that the author was making in this section was he was
saying, well, there's basically like two points if I had to boil it down, one is by stashing your changes, you're, you're guaranteed to not lose them,
right? You're there, they're going to be around, right? And you can even that, you know,
they'll technically even be in, uh, you know, references to them in the ref log and everything.
So, um, and those, those blobs are being created, you know, they're in your repo. But also the point that he's making is branches, as we are learning through this whole process, they're so cheap.
So why not just make a new branch to go back to the commit that you wanted to?
Rather than staying in the branch that you were working in, why not just create a new branch that is the commit that you
wanted to go back to? And so that's where he's going from here. Yeah. So I guess a way of kind
of making sure you got that backup. And we should have said to, you know, we mentioned using the
ref log to get back your changes, but that doesn't help you for anything that was in your working
tree that hadn't been staged yet. Oh, good point. Good point.
Yeah.
So if you were working all day on some stuff and you hadn't staged it, you hadn't committed it and you did it get reset hard.
Yikes.
Yeah.
Fair.
Very good point.
And that's the advantage of the stash here is that it would preserve changes that you've both staged into the index and ones that you haven't yet that are just only
in the working tree. And instead, both of those would be saved off somewhere in a stash. And then
the beauty of stash, if you haven't used the stash command, is that it's not branch specific.
So at any point in time, if you want to, you know, pop that off the stack, you know, you can, and I guess stack would be a bad,
a bad phrase there. Cause that would imply like, you know, some kind of a queuing, like first in
first out or something like that. But really it, you know, the stash is you can, you can put them
in there in any order. You could pull them out in any order. I guess you can't put them in there in
any order, but you could pull, you can pop things from the stash in any kind of order. You could do a get stash list and you can see all the things that
are in there. And then you're like, wait a minute, what was in that one? You can do a get stash show
and then specify the stash number. And you can actually see the changes that are in that,
that thing and be like, yep, that's the one I want. And you can choose to pop it, which would remove it from the stash, or you can just
apply it to get stash pop and then the number or get stash apply and the number and the apply will
leave it there for you. And I do like to give, you know, if I know I'm going to stash something
for a long time, this is off topic, but if I'm going to stash them for a long time, I like to
give it a meaning, more meaningful name or message to, you know, like this is what I was
trying to do at this point in time. So, uh, you can, you can do that because by default, if you
don't, then I believe the default is just, it'll give it this weird name number. That'll be like,
uh, uh, like at, and then in curly braces, a number of whatever the next
available stash is. And then it'll be like, whatever the met the current, um,
message commit message is for the current state of head at that time.
And I believe it might even put like, Oh,
no, I don't think it puts anything else. I think it's just the message, right? I'm going to try it.
I have been scared of get stash. Really? I've misused it before and lost changes. You know,
obviously I was misusing it. And ever since I'm like, yeah, you know, let me just keep,
let me just create a branch. It's easy to create branches. It's easy to edit commits.
Why don't I just create a branch? And I understand that stash, you know, let me just create a branch. It's easy to create branches. It's easy to edit commits. Why don't I just create a branch?
And I understand that Stash,
you know, I understand the advantages of it.
Like it lets me get what I want
without much bigger model.
It's really flexible
and I don't have to commit things
that shouldn't be commit.
But, you know, branches are pretty easy too.
But I'm going to make an effort
to use Stash more often
because I should really get comfortable with it. Okay, I know's wrong it does it does prepend a thing on it so it'll say um like wip
for work in progress so work in progress on whatever your branch name was that's where you
created the stash colon and then it'll have uh enough uniqueness of the commit id and whatever the
message was for the current commit message head current commit message of whatever head was at
that time or the commit of the shawl that it's showing you does that make sense what i'm trying
to say there but it in all that's going to start at the beginning with like whatever the stash id is for that thing so it'll be something like stash at curly braces
some number colon work in progress on branch name colon commit shaw commit message
so yeah there that was like one gap though that if i had to make a recommendation for the book
that there's i think there should be more about stash i think it should have gotten its own uh
you know portion of the book but i guess it makes sense that it didn't though because
if we are talking about the nuts and bolts of like get from the
bottom up,
then it's like,
you know,
who cares?
Like,
you know,
you,
you,
you learn how to use stash and move on about your day.
I think you're muted.
Oh no.
How long?
Oh,
you missed my beauty,
beauteous wisdom.
Oh yeah.
We can always do episode on get stashed with the next chapter.
It talks about it a little bit,
but not in very practical terms.
It's definitely
something I need to get better at, so I'm down with that.
Okay, so where did we add in the notes here?
I think we talked about that. I think we talked about those, right?
Yeah, I think we're
pretty much this.
Yeah, you know,
I never did GitCheckout branch. i didn't know that you could pass
a commit hash or uh you know head tilde three or whatever there i thought it was pretty cool
i've definitely been in situations where i've committed something and then like
done some you know weird jazz to kind of like go back in time create another branch off something
before that commit and you know basically if it was an experimental branch or something and it would have
been just much easier if I had done something like this.
So that was cool.
It figures that,
uh,
considering,
you know,
the,
the inventor of get right.
Yeah.
Mr.
Trivols would have like some kind of a awesome way to like short circuit
every command ever.
Yeah,
for sure.
You know,
but I too, I didn't know about that
either my my um uninformed way of doing it would have been in the case of this this get head three
or get i'm sorry head tilde three example that we were using, I would have probably, uh, like just done a get checkout of that commit.
Yep.
And then from there did,
did a separate command to create a branch off of it.
So I would have done it as two,
two commands,
which,
you know,
is awful because it's like twice as long as the other way.
Well,
that,
and plus I think that we do kind of a disservice by encouraging
people to just use the three commands that you can get by with um because uh i've like ingrained
those you know few commands that i'm comfortable with so hard that there's smarter ways of doing
things and it's not just saving commands sometimes like it's literally better ways of doing what i'm
trying to do it's safer it's more flexible. It's easier.
It's more expressive.
It's designed to do the things I want to do.
And I'm like doing these weird gymnastics and sometimes I'm screwing up things.
So yeah, I wish I would have done this much earlier.
I don't know that I would say that we're necessarily screwing up things, but I do agree.
I mean, this is the thing that I've made reference to many times, right?
I know the set of commands and the parameters that I need on like the 99% of my days. And that's what I,
that's the pattern that I use. And, you know, when I get into like, you know, weird, uh, like
get repo administrative type projects, then I'll like go digging in for like other commands and
you know things to do but on the day-to-day i still stick with like here's my here's my toolbox
of commands that i i know that i use on the regular yeah but it stinks that the times you
go looking for those new commands there's like times when you're feeling really stressed and
you just want to do whatever is like safest and you know it's going to work
you know you're like under duress well i mean maybe in the example that you're giving an example
that i was giving though i was doing like repo admin um projects so it wasn't like stress it
was just you know that's the project that's the next thing i'm working on you know i how do i get
some of those can you give me some of those tickets well i mean this is where like you know i've had
uh i don't call it the luxury uh or the pleasure i've had the task the job
of like migrating our repos over multiple times from multiple different things. I, you know, I've, I've been tasked with like,
you know,
taking repos that are,
uh,
TFS,
TFS repos and migrating those to get while also keeping all of the version
history from the TFS repo,
but making them as commits I've had,
you know,
to like migrate it from, uh,
on-prem get to Azure from Azure to on-prem from on-prem to GitHub enterprise or, you know,
to GitHub. It's yeah. So like, I've had to do these where it's like for countless,
for like a large number of repos too, not just like a single repo and so that's where like i that's what i'm referencing
when i say these times where i've had like projects where i get into like get admin repo
admin kind of mode and it's like okay well you know i need to go and do some other stuff so
you know yeah yeah i mean that's how that's how you learn uh so look at the next part so if you decide uh
so we're kind of talking about our the example we were talking about a few minutes ago where
basically we're um you know doing some admin type things and we're um you know we we if you remember
we talked about the command check out the new branch based on you know head till to something
to kind of create a new branch from a couple of commits ago. And if we decide that we want to replace our old branch name with the new one,
then there's a couple of commands you can run.
But I wasn't very impressed with this.
Like it just, this is how I would have done it.
Like I would delete the old branch name and that would create a new branch.
If you recall, this is the exact example that I gave a few episodes back when I was talking
about how, um, you know, you can't rename a branch. And I was giving an example of like how
I would rename a brand, like quote air quote, like rename a branch by technically deleting the old
branch and then creating some new branch. So that's what the author is doing here is that,
you know, going back to that example of where we did the get checkout dash B, some new branch head tilde three,
right? Where we, we're, where we combined the creation of a branch with checking out some
specific commit. Um, then, uh, now we're saying like, Hey, do a git branch minus uppercase D to delete that old branch name and then create the new branch.
And here they do a git branch minus M with whatever that new branch name is to the old branch name.
And now you've effectively, you know know renamed old branch to something new now what
does the m mean um i think that's in this case i think they were trying to set the main branch
am i wrong oh i think oh no move it's a, sorry. Okay, but you did have to delete the old version first, the old name.
Yep.
And then you can use that term, that name.
I guess you can rename the branch then.
I don't know, just.
But in that case though, hmm.
Yeah, dash M for.
There I go for looking for new documentation again.
Yeah, now I know.
This I learned.
I can rename a branch without jumping through 52 hoops like I used to.
So, dash M for move.
Okay.
Yeah, I mean, the important thing here, though, is that, like, if this is a shared branch,
then, you know, there's definitely some additional cartwheels to,
to perform, right? Like mostly around communication. Like, Hey everybody,
we're going to trash the old branch, you know, and, and if you're using that one, be aware
that it's going away and being replaced with a new version of it. Right.
Ooh.
Yeah.
So I mentioned that the lowercase M is what we're talking about here for a move.
Guess what capital M does?
Force.
Yep.
It adds a force.
So you can actually do a rename.
It's a capital M, but you have to really mean it to be careful.
Yeah.
Um,
huh.
Yeah.
Yeah.
Maybe it's a new thing.
I don't know.
I was reading something earlier today coincidentally, cause I had gotten some questions about some stuff with Git and like the
articles that I were reading were like well if you're on this version of Git then your world is
hell and like you're off over here and like here's why you're in this world of pain but you know
starting with this other version then you can do x y and z and you know things starting with this other version, then you can do X, Y, and Z and, you know, things got better. So this is why I like it. This is why I don't bother to keep up with
like, I'm not going to like every time you do a, uh, an update, are you going to like,
you do it, you do an app, get update. Are you going to like go and read the documentation
for every package that updates like namely get,
for example?
No.
So that's why I'm so guilty of like,
I'll just stick with the commands that I know.
And,
and then when I need it,
I'll go digging.
No telling how long that has been there though.
Yeah.
I wonder,
uh,
I might try,
I took a little note here.
I might try to take a look at that and try to get updated in the book.
That'd be kind of cool.
For all I know,
that one's been there forever and,
uh,
I just never needed it until I did.
Yeah.
All right.
Well,
so,
um,
all right.
So I think we already talked about the recommendations though for using the
stash and branch,
right?
Yep.
So basically,
you know,
if you've got changes that you're kind of working on, you're, you know, don't want to lose them. Like why not go ahead and just stash them branch right yep so basically you know if you've got changes that you're kind
of working on you're you know don't want to lose them like why not go ahead just stash them because
it's basically so cheap um you know why not unless you're joe and in which case you never trust
stash i'm dying to know how you like could have used stash and messed up your environment i
probably applied it to the wrong branch or did something dumb i don't know it's probably like
10 years ago. Wow.
Or I popped it when I meant to apply and didn't realize I lost those changes
and I didn't know about the ref log at the time.
And, you know, I don't remember.
It just kind of left me with a sour taste.
And I was like, never doing that again.
Yeah.
So the author, he definitely made the recommendation of like,
anytime you're going to do the reset hard stash first.
But that again implies that you have changes that haven't yet been committed
that,
and that's the reason why you would need to do the stash.
He also makes sense though.
Like anytime you're going to do anything destructive,
like why not kind of take a cheap backup?
Yeah,
he,
he made this, uh, well, I think, are we going of take a cheap backup? Yeah, he made this. Well, I think are we going to get
to it later? Maybe I won't skip to it just yet. Yeah, I think we're gonna get to it later. So
I'll pause on that thought. Okay. This episode is sponsored by Retool. Internal tools, and by that
I mean any custom software you build to help your employees operate better, can dramatically impact every part of your business.
But building internal tools from scratch and maintaining them requires a lot of engineering time and tedious work.
Retool is a much faster way to build your internal tools.
Retool offers a complete library of 100 plus fully featured accessible
UI components that you can drag and drop into any interface. It's one platform to build your
interface, connect to any data source or API, and publish employee-facing apps in record time.
It's also flexible. You can write custom code nearly anywhere to customize how your app looks and works.
And app environments, single sign-on permissions, and other critical app functionality are all available out of the box.
The result? You can build production-grade internal tools without the wasted effort of Googling component libraries, debugging dependencies, or rewriting boilerplate code. Thousands of teams at companies like Amazon, DoorDash, and NBC collaborate around custom-built Retool apps to operate better.
And teams of up to five can build unlimited Retool apps for free.
To learn more, visit Retool at retool.com.
That's R-E-T-O-O-L dot com.
Okay, so I'm going to get to it before Joe does.
And if you haven't already left us a review, we would greatly appreciate it if you did.
In fact, that was actually, I think it was Marco's comment that he said that he was basically doing this because of all my begging.
No, no, no.
I'm sorry.
It wasn't Marco.
It was Jess at Silva that said, after years of listening, he decided to succumb to my request.
Thank you.
Yeah.
So if you haven't already left us a review, we would greatly appreciate it.
They really do mean a lot to us.
It's that small
little way that you can, uh, thank us if you enjoy this podcast. So, uh, yeah, you can head to
www.codingbox.net slash review for some helpful links. And, uh, I guess there's no survey says,
since there's just one person that would be weird. Yeah. Sad. Sorry. Yeah. There's no survey says since there's just one person, that would be weird.
Yeah.
Sad.
Sorry.
Yeah.
There's no contest when it's just one person.
Why can't there be two of you,
Joe?
Hey,
sometimes there are pretty sure it feels like it.
All right. Well,
uh,
let's talk about stashing and the ref log then
all right so uh there are two ways to blobs remember blobs um what does that look binary
objects i forgot what the else is for um okay hold on i gotta look this up
this is one of those things where i feel like i use the word blobs all the time. Binary large object.
Okay, so there's two ways.
Sorry, I was muted.
I was muted because I was putting the desk down
and I didn't want to have all that noise in the background.
Are you going, blah, it's large.
It's large the whole time.
No, I was just biting my tongue.
Okay.
So there's two ways that blobs can make it into the repository.
One is the reflog, which is the thing that Outlaw has mentioned many times and is the master of,
which is basically a metadata repository that records everything you do in your repository.
And I'm trying to think of a good way to kind of express this other than, like's kind of a an ocean uh that stores uh
i'm trying to basically go for like data lake it's like it's kind of a copy of uh
we're talking about the ref log yeah we're talking about a rough log it's like a
literally a linear log of um i don't want to say commits though.
To me,
if I had to make an analogy,
it would be like a bash history kind of thing.
Like,
okay,
I like that.
It's literally like a history of the actions that you've done,
you've done and the things that get did for you. Like you might not even realize that you were doing some of those things,
but the commands that you did have these other side effects. Like for example, you do a
get pull and that's actually doing two things, a fetch and a merge, right? So some of these
commands that you do might actually be doing multiple things. And in that ref log is the
history of the things that are happening as well as the commit IDs that they were happening at.
Right.
Yeah.
And I guess the reason I was kind of reaching for ocean is that the way I the way I kind of use the ref log sometimes is usually when I kind of mess up one of my trees or I destroy one of my trees or I do something that kind of messes with the chain of commits as they're stored in inside of a tree and I want to go and try and kind of reconstruct that or try and find
something that is no longer a part of my tree and so you know it's something that kind of feels
lost to me but I'm able to kind of go diving into this history and recover it so that you know
that's my kind of like the way i interact
with this is the way i tend to think of it but i think that the bash history analogy is much better
yeah i mean that's at least the way i've always thought of it but it it's still
i mean i've looked at it several times and I have successfully like navigate my way through it, but there's still it's still in a weird kind of format to me.
This would be one area that I definitely would have thought would be more fitting.
Like when I saw the table of contents for this book, I definitely thought we would be getting into more detail about the ref log and then what,
what it did.
But you know,
maybe,
uh,
you know,
it's a,
it's a good repo.
So you could contribute to the book and submit a PR.
Can you edit the ref log?
Would you destroy it?
I'm sure it's a file.
If you were to manually edit it,
I would have to assume it's just a file under the get directory,
right? Let's go poke around. Let's do file. If you were to manually edit it, I would have to assume it's just a file under the get directory, right?
Let's go poke around.
Let's do it.
I don't know.
I don't know where that,
Oh,
I guess it's going to be the refs folder.
Nope.
I was thinking it'd be in the logs folder.
Yep.
It is the logs folder.
Yeah.
It's got all my changes right there
so my git if I do a
git log on the branch that I've been messing around
with tonight I've got two commits
but my ref log has 22
entries that's because I was
you know undoing resetting doing just
kind of messing around with all sorts of stuff and
yeah I can see exactly what I did do
wait so in your refs directory
where are you under?
Sorry.
Uh,
it's under dot get of course,
uh,
logs,
refs slash heads.
And then I've got one for my main branch.
Yeah,
but I mean,
I've got,
I've got multiple branches,
so I see multiple files. Yeah, there's, yeah. So I just went to the one for my main branch cause I've got multiple branches, so I see multiple files.
Yeah, so I just went to the one for my main branch
because I've only been working with one tonight.
Okay.
I mean, it's in a different, it's a more verbose format, it looks like,
than what's in the file versus what you see from a git reflog.
Yeah, it was kind of surprising to me.
You would think, if anything, the git reflog command. Yeah, it was kind of surprising to me. You would think if anything, the git reflog command
would kind of, I don't know, enrich
that data instead of trimming
it down a little bit.
But you can see that it maps, you know,
mirrors. Yeah.
Mirror's not a great word, but yeah.
Now, this
was one of the interesting points, though.
Like a takeaway that the author gave that
wasn't maybe intentional or or at least maybe wasn't like the point he was trying to make at
the time that i took it so i mentioned earlier that um if you if you did that get reset,
you know, like the hard, for example,
that you were setting a ticking time bomb of like when that thing would be garbage collected away.
Yep, 30 days by default.
So it's in your ref log
because it's still in your ref log,
it's 30 days by default.
But I thought that prior to this conversation,
when we were talking about like,
I don't remember if it was related to commits
or trees or branches or whatever,
but in one of the prior episodes,
I thought that the reference was 90 days
was the default, orphaned,
uh,
blobs.
I guess technically I think it was just orphaned.
Um,
what was the word?
Yeah.
I mean,
I think blob is right.
Well,
but,
but I,
I want to also include,
well,
no,
no,
no.
Yeah,
yeah,
yeah.
The blob would be correct because,
um, commits in and branches wouldn't. So any blob that wasn't referred to,
that wasn't reachable by a commit, I thought that those were 90 days. So what struck me as odd here
was at one, I was questioning myself like,, was I, am I remembering that right?
Was it 90 days?
Uh,
I thought we said 30,
but I'm trying to verify that.
Okay.
Cause then the other,
the other thing was like,
Oh,
that's,
that would be,
uh,
odd that the blob garbage collection had a longer retention than what,
than this ref log cleanup was.
What if there's a command you could run to see what that number is exactly?
Because basically said another way, the 30-day thing for the ref log,
as I recall it from our discussion so far,
was that the ref log was basically keeping 30 days worth of
stuff period uh so i thought it was so i thought it was 30 days and i think when we talked about
initially uh i talked about like wanting to know how they figured out if anything was pointed to
because it seemed like a slow operation to have to go through and look at all my trees to figure
out what was pointed out and what wasn't.
But now it kind of makes sense to me.
It's like,
Oh no,
just use the ref log,
trim the ref lock back every 30 days.
And so,
you know,
it's got timestamps in there so you can do that.
And then all you have to do is run through this ref log and see,
you know,
well,
that was the exact conclusion that I came to at the time.
Yeah.
Because I too questioned like how it would go through
like every blob
but then
at the time
that we were talking about
that other garbage collection
I was like,
oh,
now it makes so much more sense
because it could just go
through the ref log.
So yeah,
maybe it was just 30 days then
because I guess 30 days
for both would make more sense.
Well,
here's the important question
is how do you tell
what your setting is?
Like you should be able to,
you know,
under get config or something you should be able to, you know, under get configure something,
you should be able to see what your, uh, you know,
garbage collection days are set to.
Uh, yeah.
But I mean, I don't know how to do that.
I think the difference here though, um,
cause, cause there's a Git log ref,
a Git,
blah, blah, blah, blah, blah, blah.
Let me try this again.
There's a garbage collection ref log expire
flag.
So you can prune that independently,
but to see the configuration of it,
because another thing that I've been questioning too
from a garbage collection point of view
is that you're not running a Git server.
So this garbage collection is only going to happen
on the next command where it needs to make it happen.
Right.
Right?
There's not a daemon running.
Yeah, that's what I mean.
Like there's no server process running.
So even the 30 and 90 day thing, those are kind of like in quotes, right?
Because if you never,
if it's your local repo and it's not running as a service for anything, then there's nothing that's going to automatically purge that after 30 days.
So if you come back 120 days later,
you're still going to see everything and it's going to be on that subsequent
command that I think that it'll start making decisions.
Right.
Yeah.
That makes sense to me.
But I've also had times where like I've had get,
tell me I needed to do the cleanup myself.
Oh really?
But I think in that scenario that was just because of like the size of it had
gotten kind of,
it wasn't,
I hadn't passed the date yet that,
you know,
of whatever that X,
that configuration is that we can't find.
But I had,
uh,
you know,
reached some kind of size limitation that was causing problems for it.
And I forget what the error exactly is,
but it's something like the pack pack objects.
Um,
yeah.
Do you know what i'm talking about objects
slash pack yeah git identifies similar objects will compress them into a pack
packs are like zip files of git objects and they live in the git objects pack directory
yeah i mean it says that you should be able to do it from a git config though
so yeah so it seems like i should just be able to Git config list and see it.
Yeah, I did a system-l, global-l.
I was trying to figure out what the fault values are.
I do see one article on Atlassian.com referring to the Git reflog expiration
actually being 90 days by default.
So I'd really like to see that.
Well, I mean, in the git gc configuration,
there is configuration and it shows the defaults.
So I would assume that in the config, like if you listed it out,
whether it be for the local repo, global, or system,
that you're only going to you're only going to see
overrides you're not going to see yeah faults mentioned so i wanted to see the defaults but
so so check this out you're going to like this your memory is amazing uh get uh sorry gc.ref
log expires an optional variable that defaults to 90 days. It's used to set how long records in branches ref logs should be preserved.
Then there's a second setting called GC dot ref log expire unreachable,
which defaults to 30 days and is used to set how long inaccessible ref log
records should be preserved.
Okay.
So I had the numbers right, but but just for different reasons yep and the
reason you were probably seeing that that error uh that message about um the package collection
yep uh there's a various there's a couple other settings that um you know refer to kind of like
timeouts and uh various sizes when it comes to like the compression and various sizes and so uh if it um
you know if it sees that spending too much time in compression or taking up too much space it'll
recommend that you uh go and run that uh compression or sorry not compression that uh
garbage collection i i will say this though that like you know prior to going through this series right like old michael would
have gotten that message about like oh you need to go and get garbage collect manually and i would
have just been like okay do it be as aggressive as possible delete everything yeah but now i'm like
i don't know maybe i don't want to do Like maybe, maybe I want to be a little bit more selective.
Yeah.
You know, like, uh, especially like if I had some things that I'm like, you know, not in a good place, let's say.
Oh yeah.
You know?
Yeah.
And you're probably not, if you're seeing those messages, like you're probably doing some funky stuff.
Yeah.
Yeah. Yeah.
There's a lot of articles just on garbage collection and get,
it's pretty cool.
You want to know the weirdest,
uh,
get command.
What would you say is the weirdest get command by the way?
The weirdest get command.
Uh,
geez,
I don't know.
Uh,
I think,
uh,
I think they're all kind of weird
well get config is definitely strange to me that i can't see config values so i'm gonna go with
that one right now mine is going to be just based on name alone and it's the re re re
oh i've we've talked about this before have we we? We've talked about re-re-re?
I think you brought it up.
It's reuse recorded resolution of conflicted merges.
Okay.
Yeah.
I swear we've talked about that before.
No.
Get out of here.
Get out of here.
All right.
While you're searching the website.
All right.
Where do we leave off?
We have been so bad tonight, Joe. This is why Alan cannot leave you and I alone.
Cause we will not stay on script. I have no idea where we are. Um, all right. So we were talking
about, uh, blobs and, uh, we were talking about, uh, the ref log. So if you modified food, Java, but you didn't add it to the index or anything,
you can still see the blob exists by doing the get hash object food,
Java. We,
we talked about this before like at the very start of this series that you
could see like what the hash, uh,
the Shaw that would be created for that file by using get hash object.
Right. Um, so again, for that file by using git hash object, right?
So again, he talks about stashing your changes at the end of the day as a way to,
you know, stashes are cheap.
It's an easy way to go ahead and get all of your files,
to go ahead and get blobs created for them
and to get a record in your local git repo
of those changes.
And then the next day you can just come back in and do a Git stash apply and go on about your day.
Right. But the author actually takes this to an extreme. He takes it a step further and includes the contents of a shell script that you could either a add to
your local bin path so that you could run this script,
you know,
and I think he called it,
um,
uh,
what started with the S,
um,
oh man,
you can,
what was the,
uh,
get so much for that good memory that you were talking about, oh man what was the git
so much for that good memory
that you were talking about Joe you jinxed me
you jinxed me it's all your fault
I'm going
clicking
he called it a snapshot
so
yeah so he
he
gives you this command so that you could do get space snapshot
and you know it runs the the git stash and and git stash apply all in one step for you so that
way um you don't have to worry about stash applying later the next day. It's already back, but you've also
created all the blobs for you. Now that would be kind of a nuisance in my workflow though.
I don't know about you because I will periodically do a get ad at certain points when I'm like,
okay, I know that this file is like how I want it.
Get at it,
which technically I've created the blob,
right?
At that point.
Yeah.
But,
uh,
and I'll continue working.
And in the use of stash here,
your changes are going to be when you stash and then stash apply.
Yeah.
Cause the default stash action is to save. So get stash and,
and get stash apply is going to save it and then apply it out. And it's still left. He's still
leaving it in the repo cause he's not popping it. Did you notice that? Yeah. So, um, then what's
going to happen there is it's just going to be put into your working tree, not in back into the index like
I had it. So that that part would kind of annoy me. But because it's being left in your stash
history, he had a another example, another command to use the ref log to expire stashes that are 30 days after 30 days old.
But here's where he takes it even to a more extreme,
and he suggests using it in a cron job.
Yeah.
Now, would you do that?
I don't know.
I think it's cool.
I don't think I would get a lot of mileage out of it.
But yeah, the idea being
that you set a cron job for like say every hour or so and then then at any point you can go look
at the state of your files every hour which is pretty dang powerful when you think about it so
if it's like oh the thing i'd started on this morning and decided not to do now i want to do
it uh you know you can go and kind of roll back to that which which is really cool. But I don't know.
I just don't – that doesn't come up that often in practice for me,
especially with your trying to commit stuff and merge in every day.
So it's never really that far away.
The running it hourly was definitely peculiar to me.
Like I said, again, consider what my workflow is, right? Like I
would find that hyper annoying. And also another reason why I wouldn't want to cron that thing
is that let's say, let's say you had it run at the zero, zero of the hour, the top of the hour,
right? So every zero, zero, it's going to run. And you're trying to package together a large PR, right?
And you're reviewing all your changes.
It is the 59-minute mark, and you're still reviewing your changes.
And then you're like, okay, yep, I did mean to change that one.
Get at it.
Go to your next file.
You're reviewing it.
Yep, I did mean to do that one.
And you go back and look, and now this command has kicked in because it rolled over the clock rolled over
zero zero and now all of your files that you had added to the index have been
removed from the index and back to the working tree yeah like that which is rough for your workflow, but for the rest of us that just do add dash A.
Oh my gosh, Joe.
Joe.
Yeah, it's not really a big deal.
But yeah, I mean, it's interesting.
It's kind of like the use case you mentioned is definitely valid.
I don't add files kind of as I'm working typically.
It's something I do like right before the commit.
But there are some IDEs and some other tools that we'll
kind of want to add by default like
IntelliJ does this thing where whenever you create
a new file, the first time it'll
pop up and say
would you like to add this to Git
and the, if I
remember correctly, the
things, the options you have are
yes cancel and always If I remember correctly, the options you have are yes, cancel, and do this always.
But I want to cancel always.
And it's never been clear to me that there's a way to cancel always.
So I don't want to add it because I'm still working on it.
I'm just adding this file.
So sometimes every once in a while I'll get a file added you know because i clicked the wrong box or whatever so i need to make another correction can we like uh like which
errata number are we at for things that michael said wrong like eight billion one that's probably
too small number 18 billion in one should have snapshotted i just i i just did a test it did reapply it back to my index
not the working tree so his example it would work exactly like i would be happy with so okay i'm
sorry i messed up it did apply it but i'm man i'm so impressed with kit like every day the more we
get through this the more I'm impressed with this.
So I guess if you've got a big repository, maybe there can be some noticeable delay between you doing the stash and the apply.
Yeah, large repos suck.
Yeah, just don't do them.
I think GitHub has a recommendation like your repo should not get beyond
i think two gig if i recall you mean 20 gigs and i haven't had the luxury of working in a repo that
small for quite a very long time um so yeah anyway you gotta check in on your uh home movies you know
i remember i remember when i went first learning about Git and people were talking about using it as a mechanism to take backups of the operating system.
Remember, did you ever hear anything about that?
Do you remember reading anything like that?
No, I've done some stuff that was kind of nonsensical in that vein your root your root uh drive is the is the start of the repo
and then you're just like get out everything recursively get committed and then you know
yeah that's insane i wouldn't suggest doing that it's not what it's intended for i do want to call
out though the reason why that get ref log expiry command is important as it relates to the stash.
Because, again, we're continuing on with the author's example of doing this stash and stash apply.
Not a stash pop, but a stash apply workflow so often. And the reason why you want to use that ref log command instead is you might
be tempted to do a skits dash clear,
but if you did that,
you would lose all the history.
And so instead,
if you do this,
get ref log,
expire dash,
dash,
expire equal 30 dot days dot, uh, or no, that was a space
refs slash stash, then it will
just let the old stuff
age out, the old stashes age out of the system
rather than losing everything.
Yeah.
I was just looking at the notes.
I think we,
I think we hit it all.
We do.
We finished a book.
Oh my gosh.
We finished the book.
We finished one.
Yeah.
You answered this,
this book on the pole.
Then you did it.
You got it right.
Yeah.
So yeah,
just put a comment in the show notes and we will
send you a
free link to the book.
Yeah, there you go.
Yeah, I guess we should probably just take a moment
thank you, John
for putting this out in the world.
This is some really great stuff.
Like I said, I considered
myself to be, you know, a pretty seasoned get user. And I still feel like I have walked away
from this open source book with, uh, you just that much more knowledge, you know,
I don't know what your thoughts are,
Joe,
but yeah,
I,
I definitely feel like I walked away from it with a lot more than what I went
into it with.
And I thought I had a pretty good understanding before.
Yeah,
it was,
it was really good.
And it was a tight book,
you know,
like,
uh,
it wasn't like,
uh,
some 200 page,
whatever.
Like it was really concise and really got the,
got its punch card.
So,
so I,
I really liked it. It was a good read. And the got its punch across so i really liked
it was a good read and the author has like a sense of humor about stuff too so that was good
and to your point you know like some of these quote chapters were like a paragraph
yeah you know for sure like some of them are super short uh depending on like you know
how much needed to be said so yeah so uh we'll have links in the resources we like section to, you know,
obviously to this book,
but it's more specifically to this specific chapter that we're working on.
And with that,
we'll,
we'll move on to Alan's favorite portion of the show.
It's the tip of the week.
I got a bunch of them,
so I'm going to go.
Yeah,
you do.
There you go.
So it's really kind of one.
So a couple of weeks ago alan mentioned
obsidian on the show and obsidian if you don't remember uh is a it's a note-taking app that
operates on markdown files in the local directory so literally when you're setting up what they
call vault you pick a directory for it to go in and it's puts all your files there and then the
value add is basically you've got a rich client that sits on top so it's got like a nice search engine so you can search the files in that directory it's got um you know you
can do tags and stuff you can embed images and it's just got some kind of niceties on top of it
but it's all built on markdown which is really nice because i just migrated out of evernote which
i used for years and i really liked not markdown files so the migration process was rough and they
had some ways to export but it was
in some other funky you know format and so i just ended up doing it manually and deleted a ton of
stuff that i didn't feel like transitioning but in this case yeah you just you know you've got
the files so they're yours you can stick them in dropbox if you want and just use this product
totally free and you're just using the you know client. You're using the client on the client side.
But you can also pay for sync and other things like that.
So that's why you would want to use it.
So I just kind of wanted to mention that.
Yep.
Well, I guess I'm still trying to wrap my head around this thing because I don't even remember Alan referencing this.
You said he referenced it recently?
Yeah, he was looking for a note-taking app to use at work and he didn't want to like use some cloud service because he didn't
want to send his changes up he just wanted basically a nicer uh note-taking app than what
you know uh you can get via you know mac os i guess i'm just um because i use vs code a lot
for my notes,
but you're saying that this would be a better option than VS Code.
Yeah, and I'll tell you a couple reasons why.
So one, it's got that rich client interface, so it's good for searching,
so things like stemming and things like that.
You don't have to do regex searches, like not pure text.
It's got some contextual stuff in there.
It's got really nice support for cross-linking.
So, for example, if you have a daily to-do list and you want to link to some meeting notes that you took in the meetings folder,
you can just do like bracket, bracket in the name of that file.
And it knows that, okay, bracket, bracket means it's a link to something that's in this directory here.
So it's just a nice
way to be able to kind of navigate around quickly and it's got really nice support too for just for
markdown so when like you do like your um you know your text typing it basically as soon as you leave
that line it converts it to markdown so rather than having like preview pane on the right it's
mixed which is just a nice user experience it's almost almost like a, it's almost like a Jupiter notebook at that point then where like you've ran
that statement and now you just see the totally.
Okay.
Yeah.
So that's,
that's a really good analogy there.
And also it's got some port for like embedding files and stuff.
So I'll take a screenshot,
paste it in there.
And what it'll do is it'll take that image and throw it in a,
in a directory and then it just does a link to it.
And then as soon as I leave that line, it shows the image.
Okay.
Now let me ask you this, cause this is what could win me over.
I, when I'm taking like notes like this, you know,
I'll have like some kind of scratch pad, you know, for whatever notes in it,
in, you know, for years it was sublime.
And then, uh, Adam came along and it was VS code now, right?
Yep.
I do not save.
Yeah.
It does it for me.
Yeah, it does it for you.
But then you won me.
Yeah, no saving.
And also, I think, I'm not sure because I started paying for it now, $10 a month, because I want some syncing features and some other stuff with the mobile app.
So it does have a history of changes.
I'm not sure exactly how that works on the free plan.
Wait, there's a $10 plan?
Oh, wait.
No.
So I do it.
$8 plan.
It's confusing.
The thing that I pay for is the syncing feature, which I believe doesn't show up in the normal place on the pricing page.
It's kind of like how it's kind of organized is strange.
Like you go into sync and it's like, hey, you want sync?
You got to pay for it.
You got to sign in.
And so I can do that.
Alternatively, you could just throw it in Dropbox or Google Drive or wherever.
They actually have really nice instructions on that for the website.
But I don't want to deal with that on my phone.
So I pay for it because I
I'm willing to do that. I was paying for Evernote before that. So it wasn't, you know, it was a
lateral move for me. Huh? Oh, check this out. Here's another really nice thing about it. It's
got support for templates. So for example, um, it's also got nice support for like a daily note.
It just kind of, you know, it gives you a, there's a nice button you can click that will open up a file with today's date in the name you know 2022-10-whatever uh you can specify a template
that says hey every day uh it's gonna have you know there's five things i have on my daily to-do
list every day you know i like i make coffee i brush my teeth i you know that's pretty granular
things i wouldn't normally have on my list but just just as an example. And so I can set that up as a template.
So every day I get a new file with the,
the date and it's got those five things in a checklist that I can go in there
and check off,
but you can also create a custom template.
So for example,
like whenever we do like,
um,
jet brains,
uh,
contests.
So,
you know,
if you join the mailing list,
which you should go do,
uh,
on the website,
um,
there's some, uh, you know, whenever I send out a contest email,
there's some legalese I put down at the bottom.
So I have that in a template.
So I can just do like squiggly bracket, squiggly bracket contest,
you know, legalese or whatever, and it'll auto-complete that.
And I'll just drop that text in there.
Also, when people win, there's a little bit of legalese that I put there.
There's just a couple of little things like that.
So it's kind of like support for snippets basically in Markdown,
which is really nice.
Finally, or not finally, I've got a few things.
It's designed to support multiple vaults up front,
and vaults is basically a directory.
What I like about that is I cannot have my work stuff leaving my laptop, right?
So I don't want that connected at all. So I have a vault on my laptop, my work laptop,
where I have my work notes for meetings and stuff like that. And I also have a separate vault that I do have syncing turned on for that has like my daily, you know, to do type stuff. So like my
kind of personal stuff. So that way, if I get a phone call from my insurance adjuster or whatever,
I don't have to switch computers or grab my phone.
I can add a couple notes into that vault from my work computer
and I don't have to worry about any of that work stuff syncing.
Can you have certain vaults not sync to your work computer?
Yeah, so totally.
So it's up to you and it's totally separate. So it's up to you, and it's totally separate.
So it's designed from day one to support multiple vaults.
So it doesn't feel like something where I'm going through and checking the bosses.
I have to actually go kind of explicitly grab the vaults that I want to sync,
which I like.
Huh.
So also, community extensions.
People write interesting extensions that basically add ui
or various other feature features to the editor and some interesting ones i've installed was a
calendar view that lets you do i forgot what it is like you know bracket bracket calendar or
something and it will insert a calendar and it ultimately serializes to uh markdown so if i go in a notepad or something
i can go and see you know however it chooses to serialize that but if i'm in the editor then i get
a nice calendar and uh another one was kanban so if you want to have a little kanban board on your
you know so you could set it up with a template so that every day you click on my daily note for
the day today and it comes set up with a checklist of brushing your
teeth and getting ready for work whatever and also has a kanban board with all the stuff from
yesterday or whatever if you need brushing your teeth in a kanban we need to talk yeah again don't
want to forget i mean like but also that implies that it might not be the highest priority that
you're going to work on for that day no yeah no way you know what anyone that wants to grab that one can don't get me started on the toothpaste conspiracy it's my
turn to brush joe's teeth i'm just kidding i was just looking for some example of something that
i thought you could relate to but i didn't know that you didn't brush your teeth
wow way to change it out on me what you're describing and like looking at the, the, uh,
screenshots of this thing, it, it looks like, like if I had to make an analogy, like if you're a,
an Apple user using the notes program on your Mac, and then you also have that on your phone,
except here it's all in Markdown, but you can decide hey there's certain of the there's
some of these notes i don't want syncing to certain computers and with the built-in notes app it's like
all or nothing right yeah yep and uh the other things too like you know i mentioned tags so like
in my little daily checklist to do tasks i might um tag a task is like you know hashtag jira and then click on that and see anything else i've tagged
with jira so if i'm doing something with management or hashtag scrum or hashtag some feature i'm
working on or whatever uh which is nice but one problem i did run into is that i was like okay
i've got a feature that i worked on and i had a couple HTTP files that I wanted to associate with that.
And this is stuff that I didn't want to really put in a wiki
because it was just kind of not really interesting.
But when I say HTTP file, I'm basically talking about a bunch of curl commands
that are formatted a little bit nicer.
We mentioned there's a really nice Visual Studio Code plugin
that lets you interact with this.
And I want to store that next to my notes that I've been working on with this feature.
So that if someone asks me, like, hey, how's this feature doing or having some problem with it,
then I've got this collection of API calls that I can make.
And I can plug in variables and do all sorts of cool stuff.
But the problem is that everything that that obsidian manages aside from media files
needs to have a dot md file extension so when i had dot http files in there uh it wasn't showing
up for me to kind of edit i wasn't getting the history on them stuff like that and so um this
is kind of a dumb thing but uh i was able to just basically give them md extension and then when i
opened up a vs code, a Visual Studio Code,
you can just change the file type in the bottom right
and it picked up on it.
So that's, you know, something that I do sometimes,
you know, if you ever copy like a JSON file
into a new window,
but you don't really want to save it,
but you can go in the bottom right
and change the file type there.
And so it knows how to parse it
and you get the, you know, nice curly brackets or whatever the nice color auto formatting type stuff so i was able to do that
and worked great huh all right that's my tip obsidian that was a lot that was a lot to take
in all right well i'm gonna fail miserably at trying trying to follow that tip of the week.
But so my tip of the week.
So both Joe and I have recently been on the market or yeah,
on the market,
in the market,
in the market for on the market,
in the market for,
we were at the market for new wi-fi systems and i
want you know i already had a mesh wi-fi system but it was kind of i guess i don't know maybe
just getting long in the tooth i was reading some articles about how like uh it's in my particular
case it seemed like i was having to reboot it.
Like the frequency that I was having to reboot the system was starting to increase. It originally was never.
And then here in the recent months got to be like, okay, well, I have to start prioritizing devices or reboot it know, reboot it once a month or a couple weeks
or whatever. So it was just getting a little too frequent. And I was reading some things and,
you know, like some articles were suggesting that like they kind of can have a shelf life
depending on where they are stored, you know? So like, for example, heat could eventually get
to them and whatnot. So these home routers, they're not necessarily made to last lifetimes,
or at least not your lifetime. And at least in my case, mine had lasted, I don't know,
six, seven years, something like that. So I mean, I'd gotten a pretty good amount of time out of it. I'm not in any way complaining that it didn't serve me well
because it certainly did. And I wanted to upgrade to a new mesh system, but I thought,
well, if I'm going to do it, I also want to go to like latest standards, right? So like, uh, six or 60 kind of, um, wifi standards. Let's,
let me go ahead and like future proof myself so that as I get new equipment and whatnot,
uh, I can take advantage of those new systems.
So I landed on the Asus Zen Wi-Fi system,
specifically the ET8 is where I've landed.
And so I say that because on paper,
everything's great about it, right?
Like even other reviews,
oh yeah, no, no, no, it wasn't cheap at all. But, um, none of them are to be honest. Um, so this one wasn't any worse. And
in fact, this one was actually better cause I was, I was torn between an Orbi system versus
the Netgear Orbi system versus the Asus Zen wifi system and, uh, the Orbiez for the comparable system that I got from the ASUS system, it was much more
expensive. And the pro to the Zen Wi-Fi system that I got was that any one of the access points
can act as the main router. So if you wanted to add on an additional one, no big deal. You can just go to the store and buy it and add it versus the Orbeez.
If you lost your primary router,
you can't just substitute one of the satellites in as the primary.
So I liked that about the ASUS system and from everything that I was reading
and reviews and everything performance between the two was extremely comparable. So it wasn't like I was reading and reviews and everything, performance between the two was extremely comparable.
So it wasn't like I was going to lose a big – like if there was a performance gain on one or the other, it depended really on like that particular test, how the environment that they were testing in.
Because sometimes the Orbi would win.
Sometimes the Asus would win.
Point being, those two performance-wise were very comparable. So the main selling point for me became the fact that any one of the access points
could become a satellite. I'm sorry, could become the router. Any AP could become either a satellite
or a router, depending on how you needed it. Um, but my problem with it though, or one,
one of the issues that I've been, I've had with it though, is that, uh, we have talked over the
years about, um, my love of IOT devices when it comes to like the, you know, our shopping episodes, I'm always like, oh, here's all the, you know, latest stuff, right?
At least the way I wanted to configure the ASUS router,
the truckload of the various devices I have sprinkled around the house were giving me all sorts of problems. Google devices, it could be, it could be like Google,
various Google devices, Sonos devices, um, the Casa devices, all of them, just various problems.
They would like not even show up on the network. They wouldn't even see the network. So at any
rate, I found a link that Asus had, an FAQ that they had published, where they were talking specifically about how to improve the compatibility of the router for IoT devices and the recommended configuration changes that they made.
So I'm going to share that article with you.
But here's the super depressing caveat
to that. One of the things I said, like I said, was I wanted to future proof my devices, right?
So, uh, you know, like the wifi six or 60 kind of standards, I wanted to be sure that like I was,
uh, you know, I would, my, my future wifi
devices that might support wifi six could be able to use that not under this configuration.
They can't because in this configuration, wifi six is only used for wireless backhaul connections and not for any of your devices to use,
which to add more like insult to injury in this whole situation, I don't even use a wireless
backhaul because they're wired in my house. So that it's like, now I have this thing that I
wanted, this wifi standard that I wanted, this Wi-Fi standard that I wanted
that's not even being used by anything. So I don't know. I'm still trying to work my way
around this thing, see if I can get this working the way I ultimately want. But that part has been
frustrating. And then to add further insult to injury, and I'm curious, Joe, to hear your opinion on this.
So I mentioned that I had to replace a previous mesh system.
And if you recall from past episodes, you would know that the system that I had loved was the Google Nest Wi-Fi system.
I had that too, by the way,
you know,
there's there,
there are the purest out there who are going to argue that like,
Hey,
it isn't the fastest blah,
blah,
blah.
And I get it totally understand that former from the wifi standards at the
time,
uh,
you know,
that like there,
there might've been a faster wifi standards,
but again,
keep in mind that this,
I had this,
had this system for like six or seven years. So, um,
you know, yes, technically there were,
there are Orbeez that were faster or whatever, but it served me well.
And I, and I especially loved like, you know,
knowing all the Google security that came along with it and,
and it being tied to your Google account. So, you know,
like if you locked down your Google account and that's, and it's locked down too. Um, and you know, it has,
it had automatic updates, which, you know, at the time was a big deal. The ASUS has it too.
Um, but I never had a single problem with it other than this, like, you know, until recently,
like I said, you know, recent months where it seemed like it was just starting to get longer
the tooth. And the old ones, by the way way do have the same thing where anyone could act as a
router and i've actually lost two and i just was able to you know buy replacements and just grab
one from downstairs and put it up here yep yeah it's great yeah so i i super loved that about it too. Um, so this week now, and I've had this Asus system set up for now for like
maybe a week, maybe, maybe I'm into my second week. I think I'm, I think I'm near my,
the end of my second week with it. And this week Google announced the new Google Wi-Fi Nest Wi-Fi Pro system that is, I honestly, had I known that that was an,
if that had been an option when I was looking a few weeks back, I would have just bought that.
But at the time there were no reports of that. And I kept questioning like, why is it Google
hasn't put out a new version yet? Like, why is it still old? And here's the new nest wifi pro that supports the wifi six standard that I
wanted to begin with.
And yeah.
And again,
I'm sure there's some purists that's going to say like,
you know,
yeah.
Performance wise though,
you know,
blah,
blah,
blah,
blah,
blah,
blah,
blah,
blah,
whatever.
So I had the original nest wifi and then there was nest,
uh,
or I don't even think they called it that.
I think it was just called Google Mesh.
And then they came out with Google Nest.
And the Google Nest, I believe, that's the one where they added the microphone.
So you could talk to, you know, OK, Google.
You could turn it off.
There's a little push button there.
But I just hated the idea because I just really don't want that.
I really hate having microphones all over my house.
You know, I don't trust it.
I don't disagree.
And I'm sure the new ones, You know, I don't trust it. I don't disagree.
And I'm sure the new ones, you know, continued on with that.
It doesn't look like it.
I don't, I don't know.
I'm not seeing anything, at least in the quick view I've done of it.
Did you see it where it said that? And that's why you're calling that out yeah so um let me see if you can find it so there's google wi-fi which looks the same
with i think there are a couple versions of it but then there's google the next wi-fi pro
technically the one i had was called google wi-fi and it was before they, I think before they purchased Nest and before they made Nest, like, you know, started branding the Nest products within Google.
So that, you know, it was just called Google Wi-Fi is the one I had.
I think it's got the voice on it.
The Google Wi-fi does not and and from what i'm seeing from the google
nest wi-fi pro i i'm not seeing where it has the um
the the the wi-fi does uh i can i confirm that why next wi-fi yeah nest wi-fi has the mics great uh no thanks uh pro
as far as i can tell doesn't look like it it's i'm looking at a comparison chart now it specifically
does not have a smart speaker built into it i hope this is a sign that smart speakers are on
the way out i despise them but yeah so that's the point though is that like and on the way out. I despise them. But yeah, so that's the point, though, is that like, and by the way, for like a three
pack of the Nest Wi-Fi Pro, it's $400.
So that that is Zen Wi-Fi system that I was talking about.
It was like five ish hundred dollars,
I think for that system.
And the Orbi system that I was looking at was around a thousand dollars for it.
Oh wow.
So the,
this nest Wi-Fi pro at least on paper so far looks pretty promising and it's
also cheaper.
So yeah,
I would have totally bought it. Yeah. I i just kept um i i had some electricity i had some lightning issues a lot
back and so i lost a router then i forget what happened to the first one i think it just died
and then i started having an issue like you were i have to restart it all the time it's like okay
yeah now i mean that's not to say the asus sin wi-fi has some great features too on it so
one it had each access point has i want to say like three or four i think it's three
um ethernet connections that you can you make to it so you can hardwire in from there. And then there's a fourth one that acts as the,
um, connection to the WAN, but you can also dual WAN the access point. So if for some reason
you have two ISPs, you can set it up for both. So there's definitely a lot more in terms of configuration that you can do
with the asus that the google uh wi-fi systems are from going to be like from a simplicity point of
view like they're they're gonna dumb a lot of that down and just like here's the basics you get you
rolling but um you know it served me well you know so i was happy with it but yeah yeah
so um yeah so i'll have that uh a link to the that new product and yeah and then i guess alan's tip
of the week yeah so uh we got a comment last episode uh specifically for alan something he mentioned
so i want to go ahead and throw it out here so big thanks to taryn uh antipodes uh sorry about
but uh send in a tip that says remember if you remember why wouldn't it be like anti
uh i thought it was basically antipodes or something i don't know oh yeah i guess anti
i was thinking it would be like something i was thinking it was made up antipodes or something. I don't know. Oh, yeah. I guess anti, I was thinking it would be like something.
I was thinking it was made up.
But yeah, you're right.
I'm sorry.
I made it worse.
I made it worse.
Somehow I made it worse.
This is how we do.
This is how we do.
Why did I do that?
Oh, so they sent an interesting tip and you remember alan was talking about uh sneezing
and specifically how his uh wife hates when he tries to hold in a sneeze he feels like he's
gonna blow his head off right so uh taryn wrote in and said there's a trick they learned in drama
class where you can place your lower lip between your teeth so this is good
if you're on the stage or something you really don't want to sneeze you know and uh you're
playing mcbath or something and you don't have to bite down hard it's just the literally
prevents you from sneezing eventually just kind of goes away so you're not going to blow your head off. I'm pretty sure that Taryn just wanted Alan to bite his lip.
I mean, so I'm going to let Alan try this.
So maybe Alan's going to bite his lip off instead.
I'm probably going to continue just sneezing.
Yeah, yeah.
That one seems so weird.
Like if that works,
what is the science behind that?
Yeah.
All right.
Well,
uh,
Hey Joe,
what do you call a beehive without bees?
Uh,
I,
I've already doesn't have bees.
I don't know.
Any hive.
Any hive. Okay. Good. I told you I ain't gonna get any better. Yeah. bees. I don't know. An e-hive. An e-hive.
Okay, good.
I told you it wasn't going to get any better.
Yeah, good.
I was close.
I was getting close to that one.
All right.
So, you know, like I said before,
if you haven't already,
you can subscribe to us,
find us on iTunes, Spotify, Stitcher,
wherever you like to find your podcasts.
And if you haven't already left us a review,
we would greatly, greatly, greatly appreciate it.
They really do mean a lot to us.
Put a smile on our face.
You can find some helpful links at www.codingblocks.net slash review.
And while you're at codingblocks.net, check out our show notes, examples, discussion, and more. And you can go to the Slack link or just type in
slash Slack at the end of that.net and
join the Slack group and
come on in and talk.
Also, we got a tweeter at
CodingBlocks. You can head over to CodingBlocks.net
and you can find all our social links
at the top of the webpage.
Top of the webpage?
Yep.
Top of our home page
I just want to make sure you're being very clear
it's like not at the top of our myspace page
or
remember geocities
oh so good
join our web ring