Jim: 0:05

Welcome to another episode of Runtime Arguments. Uh I’m Jim McQuillen, and today, like always, is my best friend Wolf. Say hello, Wolf.

Wolf: 0:16

Hey everybody.

Jim: 0:18

So how was your week? I think you got some interesting news to tell us.

Wolf: 0:22

Uh I had a good week. Um I think the high point of my week was that um I think uh last episode we talked about uh editor theme uh syntax coloring scheme that I like called Alabaster, designed by uh a guy who goes by the name uh the handle Tonsky. Uh lots of other editors. Uh all I did was port it to Helix. Um it was in my dot files, I turned it into its own repo, I got feedback from outside. People generally liked it, and they were incredibly useful suggestions. I made screenshots, I did updates, I copied those theme files into a brand new branch of a fork of Helix and did a pull request. And in the time since me talking about it last episode and now, that pull request has been accepted. So my ports of Alabaster theme um are now in Helix Maine. How long it actually takes for Maine to uh turn into a production build, that I don’t know, I’m sorry to say. But pretty happy.

Jim: 1:41

But that’s pretty cool. It really is. And um we’re gonna talk about pull requests a little bit today uh as part of our topic. Uh we’ll get into that in just a minute. In fact, let me let me say what our topic is. We’re talking about git, uh, some of the superpowers with Git. A lot of people are using Git. A lot of people are just barely using Git, uh, kind of like me. And uh Wolf is gonna tell us all kinds of cool things you can do with Git. That some of them are advanced, some of them are things we all should be doing. Uh, but before we get into that, I’ve had a pretty good couple of weeks. Uh I talked last time about how I moved my database, my production database. Uh, I took it out of Azure. It was uh hosted by Azure, uh managed by Azure, and I I took over hosting of my database in the VM that I have on Azure. So it’s not Azure managed Postgres, it’s gym-managed Postgres. Um I did that for all kinds of reasons. Uh if you go back to the last last episode, I talk about that. Um uh but the customer loves it. The performance is about double what it used to be, which is great. Uh, it’s so much more flexible. I’m loving that. But something else I’m doing, and this is really gonna excite Wolf, I think. I haven’t told him anything about this yet. But I created an account on Claude and I downloaded. I did. I downloaded uh Claude code, and um, you know, I avoided AI for a long time. Uh, and I’ve got reasons or excuses, whatever you want to call it, why I avoided it. Um, you know, I enjoy programming so much. Part of what I enjoy, or or maybe the big thing for me, is the endorphin release that I get when I solve a problem. I I tinker with programming and I figure something out, and when it works, it’s like euphoria for me. I I don’t know if everybody gets this. I think Wolf probably does. Uh, but you know, when you work on something and you get it working, you know, and you maybe struggled for a while, there’s just something about that that is so pleasurable for me. Um, it’s it’s kind of like uh there’s other things in my life that do that too. I used to play blackjack a lot. And uh maybe I played too much, but I did pretty well at it. I won some money, I had a lot of fun, I lost a little bit of money, but overall I’m I’m up. Um uh and I haven’t played in a couple of years, really since COVID. I haven’t played, but I love playing blackjack because I love the numbers. I love adding up to 21, finding some combination of numbers that that equals 21 or close to 21. And I hope it go I hope it’s a better score than the dealer has. And that just that releases the same kind of endorphins for me. Um playing uh uh jigsaw puzzles, and I know Wolf, you’ve you you’ve kind of uh kitted me a little bit about why do I like jigsaw puzzles, but it’s the same kind of thing. When I figure out a jigsaw puzzle, when I finish it, I I get this little shot of of uh uh of euphoria, and it’s just great. Um we play some other games like when we go to Maine, a bunch of us go to Maine. We play Mexican train, and you guys probably think uh we must be a bunch of old people living in Florida. But I I love it because it’s numbers. You know, you’re you’re stringing dominoes together in long strings and solving a problem. And I just I just love that. So I’ve been afraid that going with AI, I was gonna miss that. Uh if I let AI generate my code for me, I uh and uh now that I’m sort of getting into it a little bit, I realize that’s just ridiculous. Um I’m still involved, I’m still driving the car. Um the one of the problems I’ve had though, uh keeping me from AI is I like understanding how my tools work. Right? I I know how compilers work. I’ve written compilers, I’ve worked on compilers, I know deep down really how they work, how the parsing works and the lexical analysis and all that stuff. I’ve got a pretty good understanding of that. Um I I know how network stacks work, uh, I know how mobile apps work. I’ve written some of those, and it’s not really rocket science how all that stuff works. And I know, uh Wolf, you’ve worked on browsers, you know, you know intimately how Mozilla uh Firefox works because you were uh uh an engineer way back in the day in the in the 90s. So you know what it’s like to work on things that you understand how they work. AI, I don’t have a clue how it works. You know, people throw out things like, well, yes, just this graph that that you’re traversing and stuff, and that means nothing to me. And I think it probably means nothing to almost everybody. There’s probably a very few uh number of people who really understand how these models work. Um and uh that turns me off a little bit. Um I’m kind of not excited about that part of it, but uh I am I am looking forward to the help it can give me. Um I I’ve I’ve uh uh there’s other reasons why I’ve avoided it too. I’m a little concerned about the plagiarism aspect of AI, um, but Wolf assures me that uh Claude is using licensed uh data for their models.

Wolf: 7:00

And I I I think in this case according to their their messaging.

Jim: 7:04

Yeah, and I hope that’s true. And I think at this point, I’m going with plausible deniability. I’m gonna jump into Claude and if they say it’s legit, uh, I’m I’m gonna have to go with it because you know what? So many of my friends are using it, so many of the smartest people in the world are using it. Wolf is at the top of that list. Marlon is telling me I really have to be using uh AI. He’s telling me how he’s using it. Uh Justin is using it. Lots of our friends are using it. So I’ve decided I’m jumping in. I I installed it yesterday. I’m completely lost. I’m gonna be looking for help from you, Wolf. Um, but uh I’m I’m not gonna get left behind. I I am gonna give it a try.

Wolf: 7:49

Uh so I’m super happy that you have decided this is a journey worth exploring. Yeah.

Jim: 7:56

Yeah. You know, I I’ve got a couple of uh iOS, a little pet projects I’ve been wanting to start for like two years, and I’ve just not found the time to do it. And I’m kind of thinking this is a great way to get started. I’ll integrate it with Xcode and and see if I can generate a lot of the boilerplate stuff for these little apps. There’s nothing complex that I’m doing, but it’s it’s a lot of mundane stuff, and I’m kind of thinking that uh Claude Code is going to be my uh my my pair programmer uh to help me out here.

Wolf: 8:28

Yeah, for for me, um using Claude Code is about reducing friction. Um it’s not about Claude writing new code for me, because uh I do let it uh generate code for tests and things, but everything that it does, I’m very careful to look at and understand. Um for the most part, for real code, for stuff that does your thing, i it’s like working with a very junior programmer. I’m not happy with the kind of code Claude would give me when I let it give me code. But once I tell Claude exactly what I want, then it’s like a really good editor. Like it can take that change and apply it in the 13 places that you need it in this directory, for instance. It can um decide which files need to be added. It’s great at making a useful commit message, which is nothing but drudgery for me. I’ve got it hooked up to our ticketing system. We use Jira. Uh, so it makes sure to keep my tickets up to date, to know my priorities from the tickets, to move the tickets from one column to the next. This one is in the backlog, now it’s in progress, now it’s moved to PR. Oh, it’s done. Um, and it just keeps track, which is the thing I’m bad at by myself. That’s a growth area for me, and it’s a place where I need to be communicating with the rest of my team and my boss. Uh, they need to see my progress by seeing those tickets. Having Claude do that uh makes me set expectations better. It was drudgery. Uh and nobody would look at that use of Claude and say, oh, you’re cheating. You’re you’re letting Claude do all the hard. No. It’s it’s reducing friction, that’s all. I I do want to slip in one thing before we let it go. Um, and that is uh with respect to blackjack. Yes. So um if you go in with the mindset, I’m gonna have some fun with uh eight hundred dollars or two thousand dollars or whatever, and you don’t care whether you come out with zero or twenty thousand, I support you a hundred percent. If you decide that blackjack is your profession and your intent is to make money, uh just like you know, there are people who play the lottery this way, um there it’s a tax. Uh gambling is not uh a thing that you mathematicians don’t gamble. Um and the reason is because of a thing called gambler’s ruin. And the the it’s not about odds. It’s about the fact that the casino has enough money that they last longer. Uh in real uh sequences of wins and loses uh that that are true, there’s gonna be long runs of wins or long runs of losses.

Jim: 11:50

Sure.

Wolf: 11:50

And the fact is, the casino has enough money that you could l or they could lose for days and still keep going. Yeah. Uh you can’t. So even well, no matter what the odds are, gamblers ruin can can cut your winning short.

Jim: 12:07

Sure. Sure. And for me, it was about the fun. It was never uh a way to make money, because believe me, you uh I I wasn’t that good. I don’t know if anybody’s really that good at blackjack that they can consistently make money. But it was uh it was the the the rush, the adrenaline or the endorphins of uh solving problems that I just love. Absolutely behind you. And I also my rule was always if I come home with enough money in my pocket to get my car out of the parking lot, I’ve done all right. And I never I I never gambled all that much. I hear you uh money-wise, but it was just the fun. And you know, eventually I got tired of it. I I thought I could, you know, there’s other ways I can I can get these uh endorphins. Uh but yeah, yeah. So I hear you about the gambling, and like I said, I haven’t I haven’t played blackjack in six years, and I don’t have any plans uh on the future uh to do that, but uh I I I do enjoy it.

Wolf: 13:06

Um as for Claude, uh before you go on, I’ll just say one quick thing. Claude takes direction in the same way that git uh sort of stacks up.gitignore files. Yeah. Uh Claude Claude uses Claude.md files. So there’s one uh in your home directory uh inside.claude. There’s one in your project. It’ll find anything above your project. Um so my root Claude.md file is public. It’s in my dot files. I I need to go get that.

Jim: 13:46

Um yeah, there are things in there that might be useful. And uh, you know, we did a whole episode on AI. Uh it was episode eight. That was uh today is what, episode 20. So that was quite a while ago, um, three or four months ago. So go back and listen to that. I think that was before you were really using cloud code. Uh I think that was uh maybe you were starting to use it, but now I think you’ve got a lot more experience with it. And maybe we’ll do another episode sometime in the future, uh, getting a little more in-depth in how we use uh cloud code and AI uh for what we do. But let’s get on to the feedback from previous episodes. Uh the last episode, uh, 19 was about data centers. And uh that was a fun episode. We got a lot of feedback on that, and it and a lot of people uh really enjoyed it. Uh, there’s a couple of points I made that maybe weren’t exactly accurate. Uh one of them was uh I you know I mentioned um uh uh 1U servers in Iraq. I had said it’s uh an inch and a half. Uh no, it’s an inch and three quarters. So uh uh a C a server in Iraq, a one U server takes an inch and three quarters. You can fit at most 42 of those in a standard rack. Most people put no more than 38 because they need room for a network switch and a little bit of cooling space in there. Uh so that was that one little thing. And Wolf had asked a question during that episode. Uh, when I was talking about 1.4 gigawatts, uh the the data center was spec’d out at 1.4 gigawatts. Um he had asked, is that gigawatt hours? Well, no. Uh the the spec on that is that’s the most current it can draw at any given instant. Um for instance, my house is a 200-amp service. That means the the the size of the wires coming into my house can deliver up to 200 amps. Uh at 240 volts, that’s 48,000 watts. So that’s 48k watts. Uh a data center is 1.4 gigawatts. It’s you know, it’s a couple of orders of magnitude larger than than, you know, several orders of magnitude larger than what my house uh will draw. But that’s that that says nothing about per hour. That’s just uh how much current that thing can draw. Uh when you start talking about gigawatt hours or kilowatt hours like you see on your electric bill, that’s just the electric company charging you for it. They charge you for how many hours of uh uh kilowatt you use. And you know, you might see your electric bill and it might say you’re you know 300 kilowatts or 500 kilowatts for the month. Uh, that’s all. The the kilowatt hours, that’s an electrical company thing for charging you for that. Um one more thing about that episode. Uh, you know, I I mentioned Marlon helped me with a lot of that information because he is so freaking smart with that stuff. Uh, he wanted me to point out that um, you know, I talked about how communities don’t like data centers coming in, and and for obvious reasons, you know, the the the noise, the electric usage, the water usage. The thing is, they all love what data centers can do for them, you know. Yeah, take away a data center, take away Facebook, take away uh uh Instagram, take away Google, and people would be screaming because they love what they get out of these data centers. It’s kind of like an airport. Nobody wants an airport built near them, but they all want airports so that they can travel. That’s that’s kind of like how data centers are. So that’s a good point that he made, and I and I’m glad to repeat that for you. Um I I don’t think we have any other feedback from other episodes, right? So I know I think we can get right into the meat then. You know, 18 minutes in, we’re finally talking about what we’re talking about. Um today we’re talking about Git. Um, the the uh it it’s a fast, scalable, distributed revision control system. Uh if you look at the man page for Git, it’s kind of funny because it says Git, the stupid content tracker. Because that’s all it’s doing, is tracking content for you. And in our case, the content is is source code for programs. But you can do a lot with Git. You can you can store your RC files, you can store uh uh documents. Uh you know, if you’re an author, you could you could uh if you’re using a text editor, uh you could use git to to track that. I guess even if you’re using like a word or or something, you you can use git to track that.

Wolf: 18:16

And although diff is harder.

Jim: 18:19

Yeah, diff on a on a on a blob of data is is difficult. Um but anyway, uh so Git’s been around since 2005. It was written by Linus Torvalds, the Linux kernel guy. Uh he had an itch to scratch. Uh they were managing kernel development using BitKeeper. And uh and there was a um there was a kind of a fallout uh with the company that provides GitKeeper. Uh it’s it’s a proprietary uh uh source code management system. Uh and uh they were granted a license to use it for Linux kernel development. I think anybody that wanted to develop on the kernel uh could use BitKeeper, the license extended to that. But then um uh Andrew Trigell, the guy behind Samba and Rsync, uh he tried to reverse engineer the protocol for BitKeeper so that he could write some tools that could interact with with the BitKeeper uh repository. And um uh the BitKeeper guys got angry and revoked the license, which is not good if you’re a kernel developer and you’re relying on that to to uh manage your source code. So Linus did what Linus does, he just wrote his own. And uh apparently it took him like two weeks to get it into a working state, and once he had it up and working, he handed it over to somebody else to maintain it. He’s not really involved in it anymore, although he’s probably uh a huge user of it. Um but it’s a brilliant tool. Uh, and you know, almost everybody writing software is using it. Not completely everybody, there’s other solutions out there, but an awful lot of people are. Using it. And I think a lot of people are like me. They kind of use it and they don’t really totally understand every aspect of it. So here we have uh Wolf. Wolf knows more about Git than anybody I’ve ever met. When I have a problem, it is so comforting to know. I can ask Wolf uh, you know, what’s going on here, and he explains it to me. And and he turned me on to Git, I think, in 2017. So I’ve been using it for uh like eight and a half years. And uh every time I’ve had a problem, he’s been there to help me out. And uh I don’t call him so much about this stuff anymore because he did such a good job of helping me. Uh, but I have to think that all the questions that I’ve asked him over the years, uh, a lot of people out there probably have similar questions. Uh so we’re gonna talk about those and we’re gonna discuss some some features of Git that you probably don’t know exist, but once you do, you’re gonna think that’s pretty cool. I’m gonna start using that. So I don’t know, how do we start this thing, Wolf? Uh what do you want to say?

Wolf: 20:57

There there is something I wanna start us off with, if that if that’s okay. Yeah. Um so you know, Git has its own philosophy and its own reasons, but I want to talk for just a second about the thing. Why git? Why should you use well, source code control at all, but git in particular. And the reason is source code control systems, um, and I have experience uh with how and why this is true for Git, they provide a kind of safety um that is uh super, super high level. You are everything that you commit is safe. Um if you also push it, uh which we’ll talk about later, um, then it’s safe even from the idea of your disk failing utterly. Now, things that you haven’t yet committed, uh uncommitted changes, what we modifications in your working directory, those are completely unsafe. So don’t get confused. If you delete those, they’re gone. If you commit them, they’re available forever no matter what happens next. Um as long as there’s a repository with those commits in them, you can get them back. So safety is the core. Uh and on because of that safety, because you can get back anything the way it used to be, that means you can experiment. You can try things, and when they don’t work out, uh you could go back, and when they do work out, great, that’s the new world. That’s where you are. So Git is like the answer to all of these problems that you didn’t realize were the problem that you are having. Um that’s the whole reason to listen to the rest of this episode. Because your source will be safe, you can try things when you didn’t realize you could try things, and you can get back to where it was still good. Um so that’s something I wanted to get off my chest right away. Uh, and I feel like from here we should talk about the things that you encountered on your Git journey and what uh what’s important about those things.

Jim: 23:27

Why don’t why don’t you you tell me what it is? The top of the list, you’ve already mentioned it. Let’s get into it a little bit. But commit. Uh what does it mean to commit?

Wolf: 23:37

So Git is different from any previous source code control system. Uh and since Git, other things do do this. But as far as I am aware, Git was one of the first, and that is this. When you get to a point in time where things are good, um Git takes an atomic snapshot. When you say the word commit, the things that you have collected together to be part of that commit, that exact version gets saved just the way it is. Now, before this, in the olden days, uh they weren’t atomic and they weren’t snapshots. Instead, um, like CVS, for instance, would say, okay, uh, we’re working on the file main.c. Uh main.c got these changes, and now there is a file that essentially is main.c, but with hunks that are, and then these changes, and then these changes, and then these changes. Not at all a snapshot. Um Git, you can actually look in the thing it calls the object database, which is what’s inside that.get folder, um, and you can pull out individual objects. Where a file is an object called a blob. Uh they’re all compressed, and and there’s things layered on top of that that aren’t really part of the underlying model that makes it even smaller. But the whole history is there. Um, and except for these things layered on top, it’s not about deltas. Yeah, you can diff two things and find out what actually changed between these two things, but that’s the thing Git actually does on the fly. Um, so that’s what a commit is. A commit is a snapshot, and it’s a snapshot at an instant in time. Um there’s important stuff to know about commits. Commits are the fundamental unit in Git, and every problem you solve has something to do with commits. So there’s a couple of things that when you’re building a new commit, you want to make sure you get right so that later, when you have to use one of these techniques to solve a problem, your commits help you instead of hurt you. Um so one thing is there are standards or uh suggestions for how to uh lay out your git commit message, like what to say and what to mention, and that the summary is a short line so that it can show up in all the tools that so show short things and uh you know what kinds of things you should put in it and how to reference things, you know, stuff like that. So definitely format your message correctly. Um your commits in your own before you have arranged them, and there are tools so that you can use commit in the same way that you might use save when you’re working on a Word document or in a text file or whatever. Uh you could just commit over and over again, and each commit is just my current save. Um the thing you want to present to the world is a chain of commits, if it takes three, you know, or if you can do all in one, fine. Where each commit in that chain is one thing. A complete idea that runs, builds, does whatever it is by itself, so that if you went back in time with your with your repo to that commit, your thing, whatever you’re building, could run. But if you take the whole branch or what whatever you’re working on, the chain of three, um, you’ve added a complete thing that took three features to build. So each commit does one complete thing, each com commit builds, and you try to go in a straight line. When you make a commit, um there’s the easy way, you can say get commit minus a. It’s stuff that makes it be everything you’ve changed becomes part of this new commit you’re making. I don’t do it that way. Um and as you get more advanced, you won’t do it that way either. Uh instead, there’s this thing called the staging area. It has a couple of different names. But what the staging area is, is it is an exact picture of what will be committed when you say commit. Um so you have modifications. I changed this file and that file and the other thing, but you only add main.c to the to the staging area. You stage it. You say get add main.c. If you say commit right at that moment, you make a brand new commit that only has add.c. And if that was the right thing for your commit, that’s that’s the right thing. So learning about this extra thing that you never had to worry about, the staging area, that’s part of your journey. Um when you want to undo something, uh, modern versions of Git offer the restore command. Um if it’s kind of a big thing and you’re not gonna you might want there’s another command called reset. Sometimes that comes into play. And a really, and this is gonna be the last thing I say about commits, as you’re building up that staging area, as you’re putting together what’s going to be your commit, maybe you were editing main.c and you were actually sticking in two different things, two different features at the same time. Um you’re making it take parameters, and you’re also making it um not uh work on top of um map tiles that are in Florida. I don’t know, something like that. But two totally different features. You just happen to edit them all at once. Um instead of just adding and committing main.c, you can add interactive and you can step through the the your terminal will show you this, the hunks of changes in that file. Each hunk is a uh sort of a touching, connected set of lines that changed. And for each one of those hunks, you can add it or skip it, or um it might be that you can actually split it into smaller hunks. You can’t always do that, but it uh sometimes. So add interactive lets you make the two commits that you meant instead of the one commit that would have been easy.

Jim: 30:45

Um I’ve used this a few times and it’s it amazes me every time. And yeah the way I see it works is you do a git add minus i and it pops up a little user interface, and it’s not very intuitive for me anyway. I have to relearn it every time I do it. But the minus i causes it to be interactive, and then it steps through the the hunks and it shows you the little hunk, and you can decide you want to add it. And when you’re all done, you’ve added some hunks, maybe not all of them, and then you do your git commit, and that commits that change, and then you go do the git add again, uh, and maybe you want to get all the rest, so you just say git add, or maybe you want to get part of it again, and you so you do git minus i. So you do this until you’ve committed everything, but it’s all separate commits, and it’s it’s pretty slick. I like it. That’s a superpower, yeah. So uh so you know the first thing you gotta do if you’re using a control source code control system is you’re gonna make changes and commit them. Uh, once you’ve committed a few things, then like me, I want to look at what’s out there. What did I change? What did I commit? What what are my commits? What’s the history of what I did? Um, and there’s a number of commands you can use for that. Tell us a little bit about those.

Wolf: 32:01

Um there’s tons of ways of looking at things. Um, probably chief among those is git status. Um I actually and let me say right now, um, git status prints a lot of stuff. It prints the things that you’ve added that are ready to be committed right the second. Things that are not added, uh, it can also, if you ask it nicely, print the things that are ignored, because we talked about the ability to ignore things. Um use git status with no options, git status prints instructions on how to take things you’ve already added and make them not be added. Oh, it was a mistake. I don’t want to commit main.c. How do I make it get not be added? Right.

Jim: 32:55

You did a git add on a file and you realized you didn’t really want to add that file. So you can undo that with um I I’ve I forget the command. I I I don’t bother committing it to make it. Git restore minus minus staged. Yeah. Get status always tells me what to do.

Wolf: 33:11

That’s right. So now I say git status constantly. And I are I know those instructions. I can always get them by saying git status. But there’s a thing in git you can do, which is a configuration option. You can set it in your.git config. Um it’s called an alias. And I have aliased uh st git get st to mean status minus s. Uh I think you can also say minus minus short. And that doesn’t print any messages. It’s actually um a very compact list of what the changes are. I do that constantly. Um I absolutely do it before a commit. I absolutely do it when I get into a brand new directory that I was working on yesterday or whatever. So git status um super important. Uh a thing that you might use git status for is to see do I have any modified files at all? Do I have any added files at all? Uh, for instance. That’s so important that to me anyway, and to everyone that I teach this to, it is worth modifying your prompt. Um so my prompt shows me the branch that I’m on, and we’re going to talk about branches in a second. If I have any modified files at all, I’ll see an asterisk. If I have any added files at all, I’ll see a plus. If I have any brand new files that could be added, but haven’t ever been part of the repo yet, um, I see a percent sign. There are multiple ways to get your prompt to show you these things. Git comes with, um, if you have the the actual git repo, if you’ve cloned git itself, um, you can grab the git PS1 prompt, and it’s it’s a shell function that you can call from your PS1 so you’ll see it. Or you can do the easy and in my opinion, significantly a better thing, which is use one of the existing prompts in the world. I use Starship. Um, it’s super fast, it has tons of modules. Um Git is one of them, and it does all the things that you want. Um so now you’re showing it.

Jim: 35:46

Yeah, in your in your prompt that you’re sitting there in bash or Z shell or whatever, and uh normally it would show like what your current directory is and maybe how you’re logged in. You know, if you’re logged in as yourself or if you’re super user or whatever. Uh but you can show additional stuff in there just by modifying the PS1 environment variable. Uh there’s a couple other things you can change too. But in your case and in mine, we display if if we’re in a uh a direct a subdirectory of a git repo, it’ll tell us a little bit of information about that repo right at the command line. We don’t have to type git status, it’s just there.

Wolf: 36:23

Right. Stuff you really want to know. Because in a world where, and this isn’t everybody yet, but maybe by the end of this podcast it will be. But in a world where there are multiple branches, knowing which branch you’re on, am I committing to the right branch? Because usually a branch is I’m gonna try to do this thing. And when you’re editing a file, it’s probably about trying to do this thing. So you want to be on the right branch.

Jim: 36:53

Yeah, I’ve got the branch in my prompt and it and it helps. It uh it helps me know which system I’m on because we we use git to deploy our software for our clients. And if I’m on their system, they’re they’re in the main branch. So that’s my indicator. I don’t want to be making changes here. If I forget which system I happen to be logged in on at that moment, the prompt helps me figure that out.

Wolf: 37:16

Uh so uh the actual way that commits are all arranged is uh more complicated than I’m about to say. But it’s I don’t want to get into it because I don’t want to uh lead you guys down a path that has nothing to do with the things we want to talk about. But as we’ve been saying right here, uh often what you care about is that the sequence of git commits that you have made is just that. It’s a sequence, it’s a chain. There was the very first thing you committed, and then when you made changes and committed that, that came on top of the previous commit. So if you’re at commit number eight, you could say git log, that’s one of the commands, and see all eight of the commits that you go back to. This is uh these commits define what is in the source code that you are looking at right now. So git log um sounds simple, uh, and I’m not gonna go into all its powers, but if you do help about log, log can be used for so many things. Um you can find commits by specific authors, commits that changed specific functions, added or removed specific um strings, um, happened in a particular date range. You can show just the summary line, you can show the whole message, you can show only commits whose uh commit message named a specific uh ticket, whatever your ticketing system is. Log is gonna be your friend. Um another thing that is your friend is uh git show. Um with no uh anything besides uh git show, it’s gonna basically uh show you exactly what happened in the commit that is the thing that just got committed.

Jim: 39:25

Right. So you let me interrupt you for a second. You do a git log and it shows you a commit ID and then a summary of uh well it shows you the commit message with some other data, like the time and who did it and stuff. It’s primarily it’s going to show you your commit messages, and it’ll show you the most recent one at the top, and then the next one, and the next one access. So you got this commit ID, and with git show, you can say uh git space show space that commit ID, and it’ll show you a it’ll show you the code that was in that commit. It’s like a big diff, right?

Wolf: 40:00

That is exactly what it is. And you can do that with any commit anywhere in history on any branch. Yeah. You can show uh individual files. Um Git show is super powerful, and Git Show takes a lot of the same uh option flags that diff does.

Jim: 40:21

Yeah, and you you mentioned uh if you do if you look for help on git, there’s a couple of ways to do that. Uh the one I use all the time is uh if you’re on a uh a Linux box or a Mac, um the man command, and I’ll type it like man space uh git hyphen show. And it’s the sh it’s the man page for the show, the git show command. Uh man space git hyphen log and it’ll show you that. Um you can also isn’t isn’t there a built-in help in git? Can’t I say like git show help or git help show or something?

Wolf: 40:54

Git show minus minus help. And by the way, the thing you just said is very interesting because if you happen to be a scriptor and you write a script or program, whatever, named git-uh foo, that and you put it on your path somewhere so it’s executable. If you’re in the terminal in a repo and you could call git, you can say git space foo, just like foo is a git command, and it’ll run your script.

Jim: 41:27

Really?

Wolf: 41:28

Yeah.

Jim: 41:29

I did not know that. Anyway, keep keep going. I didn’t mean to interrupt you there.

Wolf: 41:34

So diff is fundamental. Um when you show something, if you’re just showing a single commit, that’s gonna show you the diff between that commit and the commit right before it. What did this commit introduce? Now remember, a commit is actually a snapshot. So git is calculating that diff on the fly. Uh and just like show and just like log, diff takes a ton of different interesting parameters that can um make it uh do what you want. Uh in particular, uh minus minus uh name only, uh instead of showing you uh changes inside files, it just shows the names that changed.

Jim: 42:21

Yeah, so if you do a git show, a commit ID, dash dash name only, and and I forget which order those go in. Does the name dash dash name only go after or before? I don’t remember. But uh you do that, and instead of showing you the diff in in each file, it just shows you the name of the file. So you can see what files did this commit touch.

Wolf: 42:43

And if you only want the Perl files out of that, then uh a thing you could do is pipe that into uh grep and then give an expression that said dot pl. Um and then you would have just the perl file. Anyway, um but a thing that people love to do in Git, uh, and then once they run it, they are sad, um, is git blame. Yes. Um I think it was called annotate. Uh I don’t know what people want to call it. Blame seems very, I don’t know, political to me. But the what Blame does is it will tell you um for any line, uh it’ll show you the whole file. Um usually it’s integrated with editors as well, so that uh you can s actually see the lines and scroll around. And but what it shows you is the commit ID that that line was last changed in. And from that, you can know if you wrote your commit message right, why did this line change? Who changed it? Now, the reason most people run git blame is because they’re like, who in the oh my god, who did this? This is ridiculous. Why would they write that? This is me a couple of times a week. They say get blame just to find out who the you know criminal is. And it’s them.

Jim: 44:17

It’s like, who would do that? And then it turns out it was me, yeah, just like the day before yesterday, right?

Wolf: 44:24

Yeah. So all of these things are non-destructive. They show you information. Um, git log shows you a list of commits strongly related to git log is um a thing you absolutely need to remember, and that is git reflog. R-E-F-L-O-G. Why am I telling you to remember this? Because git reflog is the thing that helps you get back to a place that works. If you didn’t do the things you need to do to make experiments be okay, you know, do your experiment on a branch or, you know, whatever it takes. And make your commits the right way, the reflog will show you where it was good and help you get back to that place. Um, and it turns out there’s two kinds of reflog. They they both look and act the same. But one is for this branch, um tell me what commits happened on it. Where was the head of this branch? What things did you do? Oh, I merged, oh, I rebated, oh, I other stuff you haven’t heard about yet. Um, but there’s also one, if you just say get reflog, that’s not the reflog for any particular branch. That’s all the places your directory has been checked out to. So if you have three branches, main and develop and weird experiment, and you switch between those. Um, so first you’re on one and then the next one, and then the third one, there’s three entries in the reflog. And they say why. One says on main and one says on develop. Um so you can see where you’ve been, where you’re actually looking, what the editor says. Um reflog is gonna save your butt. Um so I think that’s everything I want to talk about about showing things, and we’re not going nearly fast enough.

Jim: 46:39

No, this is gonna be a long, uh, a long episode. Um, but it’s still interesting stuff. Um so one thing you you sort of drilled into me way early on when I started using Git was to use branches. Now, primarily we have a main branch and a dev branch, uh, but occasionally I’ll create a uh a feature branch. The the idea between main and dev is uh main is what I give my clients, dev is what we’re working on. When we’re when we’ve made a bunch of changes, committed them to dev and we’re happy with it, then we’ll merge dev into main and deploy that to the client. Uh but you you keep telling me I should be using all kinds of branches, and I do somewhat when I’m working on a feature. So tell us a little bit about that.

Wolf: 47:24

Branching at all is a superpower. Um this gives you uh at least this one really important uh feature, which is instead of a world where all you have is I’m working on the source, and if an experiment goes wrong, I can go back in time with the reflog, instead of that world, you can have this world where you have a branch, which is one course of development, um, and let’s call that branch release or main or whatever you want, and you make promises. Git doesn’t help you with these, this is just a promise you and your team make together. You say release always builds and passes all tests. If at any time we need to give somebody the very best uh working instance of our product with every bug that we know of fixed, it may have bugs in it, but n we don’t know about them yet. We can just build main and hand it to them. Or release, whatever we call it. And then you could have another branch that is develop. And develop is everything that’s in main plus some other stuff. Whatever you’re working on that isn’t ready to be released yet. Um, isn’t finished or doesn’t you know, might might have bugs.

Jim: 48:56

You’re not ready for other people to see this work yet. You’re you’re in the middle of making changes. It’s a draft. Exactly. Yeah, it’s a draft.

Wolf: 49:05

Yeah. Now if you’re on a big team, um, you know, four people, let’s say, uh, it’s totally reasonable that each person has branches, especially if you’re in a situation where you have to do things um at multiple at the same time. So you would have a thing we call a feature branch. And a feature branch is just what it takes to implement this one thing. And when that feature works, maybe you merge it directly back into release after your whole team has code reviewed it. Or maybe that means it’s ready for develop to see how it interacts with all the other stuff people are working on. Are there any logical conflicts? Um, but the notion is that if you only look at this one branch, nothing else is there to interfere. It’s main plus the stuff you are doing just for this one feature. Another thing you might use a branch for is there are points in time, like you have customer A, and customer A got a release in March. But, you know, now it’s December. So Maine has moved on, but for whatever reason, they don’t have a dis a December release. Uh what they’ve got is from March. Um and now they need a hot fix. There’s some bug, it’s a problem, you didn’t know about it before, and you need to fix it. What you do is you go to the commit that is their release. Um, this is the s the soul of a thing we call reproducible releases. Um, and your release is probably tagged, that’s a thing we can talk about later, and you make a branch off of that. That branch is a hot fix branch. You figure out how to fix that bug on that branch. And then you, when it works, you ship them a release from that hotfix. So now they have exactly the release they already had, plus only the fix for that one bug. But that bug fix, a commit, isn’t on release itself yet. It’s branched off of release. So now you also do a thing that we’re gonna talk about called cherry pick. You cherry pick that release fix or merge, either one of those is fine, back onto the main release branch. Now everybody has it. They have exactly the release they want, you’ve got the bug fix, everything is good.

Jim: 51:54

I’ve done that. It’s very, very powerful. It’s really cool.

Wolf: 52:00

Um yeah. There’s two other tiny things I want to say about branches. Um I told you enough that that you would understand why you want to have them. But how do you focus on one branch or the other? How are you making changes on this branch, but not on that branch? And how you do that is you use the command get switch, and then you name the branch you want to go to. Right. So you’ve you’ve created a branch. When you do that, that’s your current branch now. Um, and you can switch back. Make your commits, make sure that you don’t just leave changes hanging around. Right.

Jim: 52:44

I mean, so now you’ve got you’ve got uh your main branch and you’ve got maybe your dev branch for development, and then you’ve created a feature branch. You’re working on this. Now you’ve got three branches. You can do the git branch command to list them, right? It’ll it’ll list all the branches you have. And then you can do git branch uh git switch and then name that branch if you want to get back to main, git switch main. And that takes you back to main. And it’s pretty cool.

Wolf: 53:11

And it’s now a thing to know is this if you have modified files in your working directory and you switch back to main, but you didn’t add or commit those changes, well, they’re not part of a commit. They’re files in your working copy. And that means they’re still going to be modified when you’re back in main. Right.

Jim: 53:33

They’re still in your working directory.

Wolf: 53:36

Right. In other words, changes follow you. I mean, that’s not really what happens, but that’s the way to think about it. Changes follow you. Yeah. So if those changes aren’t actually appropriate for main, um there’s two answers, uh uh a good one and uh okay one. The good one is commit them, um, because maybe they’re you’re ready to commit them. And the okay one is stash them temporarily. Git stash is a command. Um it doesn’t matter how git stash works, just the fact is those files will be safe, as safe as if they were committed, because it turns out they are. But they’re in a little holding place called the stash. They’re in a little holding place. Uh a thing to know about the stash is don’t use the stash for long-term storage. Set some things aside with the stash so you can do some operation and then bring them back quickly. If you have stuff you want to keep around for a long time, commits and branches are the way to do that. Um and finally, there is one other situation that is super confusing to get to the sounds scary. It does sound scary. Um, and and that is this. First, I have to give you this little backing piece of information. A branch is really just a name that points to a specific commit. So when you switch to a commit, all you’re doing is saying, hey, working copy, you now need to be a reflection of what the snapshot looked like in such and such a commit. But the magic of a branch is, if you’re on a branch, if you’ve switched to it, if you’ve checked it out, whatever, and you make a new commit with changes that you’ve added, the magic of a branch is that name, the branch name, which is called a ref, by the way, gets updated to point to the new commit. It advances as you grow the chain of commits. Okay. But y pointing your working copy to a specific commit doesn’t need to have a branch. So I could check out some commit in history, but now I’m not on a branch. Um and if I make another commit, there’s no magical name that points to that commit that gets updated and moved. And more importantly, because nothing long-lived points to that brand new commit, um it is dangling. Um that means that if you don’t act, that commit will be garbage collected in some amount of time, 30 days, 90 days, uh, and you can set this um in your config. When you do this, the instant you do it, git reports to you the danger of your situation, and it tells you with completely obvious terminology. It says, you are on a detached head. What what does that mean? How are you supposed to know what that means? I don’t know. Um, but that’s what that means. You’re not on a branch. When you’re on a detached head, you can make a branch right where you are, and that’s probably what what you want. Yeah, this is the same thing.

Jim: 57:10

The safe thing would be do a uh git switch and then some tag name or some commit ID to get to that point in time, and now you’re on a detached head, so now you create a branch and now you’re safe, right? You got the right.

Wolf: 57:25

And in fact, you can do that all in one step if you want. You can say git switch minus C, the new name. Uh minus C means create. Um then as a final argument, where. Um and where is any other ref. It could be a tag, it could it could be a commit hash, whatever.

Jim: 57:45

Okay, so now you’ve got a branch, and now you can make your commits and stuff, and uh and uh you’re safe, it’ll be saved. Um and then you can decide to either throw it away or or merge into dev or into main or whatever you need to do.

Wolf: 58:02

That’s exactly right.

Jim: 58:03

And if you do throw that branch away, you don’t lose your original code. You only lose whatever you committed on that branch, right? If you throw that branch, if you delete that branch. All right, so you’ve talked a lot about references. You mentioned reflog and and commits and and and stuff, so why don’t we talk a little bit about really what references are?

Wolf: 58:25

Um okay, so the we we talked about the idea of snapshots. And a snapshot means that the entire picture of your uh working directory, your working copy, um is stored in individual objects in the object database. This actually turns out to be way more efficient than you thought. Uh the reason is maybe you commit three files, but every other single file is exactly the same. Well, in Git, a file doesn’t have a version. Um there’s a piece of content, and it if it the content is the same in the previous version and this version, then it’s just the one object, it’s the same object. So all that changes when you make a commit is um the chain from the deepest file of this tree of objects all the way up to the root, and then there’s a new object added that is this commit object at the top. So the kinds of objects that are in the object uh database, forget, are blobs, that’s a file, uh trees, that’s a directory, um uh commits, um that’s the t the root of one of these snapsh