Searching Git Logs

[00:00:00]
>> Let's take this repo, and you're never gonna guess what we're gonna do. We are gonna clone, but we're gonna bisect as well. You would never have guessed that, would you? All right, so if you don't have the course open, it's just github.com/ThePrimeagen/git-bisect. So you can go to GitHub and go grab that.

[00:00:16]
So we're here, now we kinda have a classic problem. This happens about once, twice, a few times a year, where you have to do this, where there's a whole bunch of commits and something has gone wrong. You don't know when it's gone wrong, you just know a while back, it's good, and currently, it's bad.

[00:00:35]
And you wanna find out exactly when did something go wrong. And so this is called git bisect. It's not a common problem, but I definitely run into it. And the longer your testing cycle is, the more you should know that this exists. Because if it takes you one second, I'm sure there's a bunch of people are just walking back ten commits at a time, they don't even know git bisect exists.

[00:00:54]
So therefore, they're just like, I don't have to care. But if you have a ten minute testing cycle, all of a sudden, you wanna be as efficient as possible, right? So, but there's a lot of different ways we could do this. One cool thing is with logs, you can actually search through logs.

[00:01:09]
And this is kind of a neat technique in the sense that if you just wanna find a change around a particular component. And everyone does a pretty decent job at putting in good logs, you could find a change around that particular component even if it's spread across a couple different files.

[00:01:23]
So that way, you're not just looking at a specific file, but maybe you're just looking for a usage of a specific item throughout the code base over time. And so you can grab all those things. Obviously, some of the cons of using logs is that sometimes you don't know a keyword to search for, right?

[00:01:37]
You know there's a bug, but you have no way you could really look through the logs to know why or where that bug change could be. Commit messages aren't always the best. I know we all say we're gonna do better, our good commit messages starts tomorrow, and then it just doesn't happen.

[00:01:53]
Sometimes you can't boil it down to any specific word, or there's just too many commits to the file, right? There could be hundreds of them, so you're like, okay, I can't just do a quick check and grab it. One reason why I tend to just do a quick log look is let's say it takes two minutes to test to see if it's good or bad.

[00:02:08]
And I know the file that is probably in, I could do a quick log search. Look at that, there's one change here. I'll just test this one change, and if that one is the problem, I'm like, God, right? You can just kind of look at the change and go, okay, this is pretty simple, I can see exactly why.

[00:02:24]
So it can be pretty fast. So you can actually search. You can search with logs with grep. But before we do that, we gotta do this, this little npm i thing, right? This is a node thing, okay? So do a little npm i, are you making fun of me for using npm?

[00:02:43]
>> No, I have to install npm, I don't have Node on here.
>> [APPLAUSE]
>> [LAUGH]
>> That was amazing. If you didn't hear, there's someone here without Node, how great is that based? You are now the new coolest. Do you wanna come up here and be UI- [INAUDIBLE]

[00:03:01]
>> [LAUGH]
>> You don't have to participate if you don't want to, it's pretty easy, it's step-by-step.
>> [LAUGH]
>> You may, all right, now that we did that. All right, so next, try to run test, npm run test. I actually did Node specifically cuz I figured there's no way people aren't gonna have Node [INAUDIBLE].

[00:03:18]
[LAUGH] Man, I can't believe this actually have. This is so great. Okay, npm run test. I didn't wanna be like, you don't have cargo? Well, let me tell you about Rust, I wanna be that guy. So yet here I am, telling you about Node. So I intentionally just put a sleep in here, so you have to wait 30 seconds to see if it fails or not, right?

[00:03:38]
This is real life, right? This is what happens in real code bases. It takes a lot longer to figure out if something is broken or not broken. So you really don't wanna have to live this life constantly, right? Right, thank you for agreeing. I do appreciate that. All right, there we go.

[00:03:55]
One failed test, expected 138, but we received 140. Dang, that stinks, right? You can actually see it right there. See, I told you, I'm literally just sleeping right there. All right, fantastic, we got that all done. Observation, we know that the foo function is failing and the test foo are failing, right?

[00:04:13]
So we know that something's wrong with the function called foo. So what we can do is we can use, by the way, I say you can do man git-log and search the logs. If you don't know in all the computer speak, searching is called grep. These modern Zoomers these days just use the term search, and they don't even know about grep, and grep is fantastic.

[00:04:31]
So if I told you to go in here and find search, you just wouldn't really find the thing because it may contain the word search, but none of them actually are grep. So you gotta use grep, right? And there you go. So you can do a grep with the pattern.

[00:04:46]
And so this is from the log, you just simply get to look through any of the commit messages with the word foo in it. So that's a strategy we can do. So I can go git log --grep foo. And so look at this, this is not about foo, this is not about foo, it's kinda hard to search.

[00:05:01]
I mean, this one sounds pretty suspicious, altering foo for new specifications, right? That sounds pretty good. What you can also do is you can actually use -p. -p also puts the changes in here. So then you can go, okay, well, what are all the changes? And as I search through, this looks pretty suspect, right?

[00:05:19]
So learning a thing or two about searching the logs can be very, very useful. Because sometimes you can stumble upon things, or you can look at changes over time for a specific item, and it's kinda nice being able to use. So there we go. So grep, that's what we're using.

[00:05:36]
And so we are able to easily find the problem right here just by looking at it. Obviously, we know the problem, right? It's a very trivial problem. We're two off, and look at this. I don't know, we times by two, and that one exactly fits the need. So we got lucky on that one.

[00:05:51]
The problem with this is this is also a lucky search. So if you're looking to solve a bug, definitely, this one error's on the side of luck to be able to get a good term with a simple set of changes that you can just look at, and it's like, there it is.

[00:06:03]
So I often don't use this, but every now and then, I'm like, ooh, there was this change I did a while back, and I wanna be able to just go straight to that change and go look at. And so I can kinda know in my head where or how I'm doing something.

[00:06:14]
So I like searching. Okay, number two, you can also search by file. So we already know that the problem is in the index file, I think it is. There's only one file in here. Yeah, there's only one file. Okay, so you can go git log and we'll do a little -p, and then we can go src/index., is it js or ts?

[00:06:34]
What are we at? Yeah, and then you have to do a little dash dash. You're gonna only search in the log with these specific files. And this will actually get you the change set only for these files. That's it, so there's only been two changes in this file.

[00:06:50]
And so this is a nice way to be able to reduce down the change you're looking for to a file. You can pass in multiple files, very, very useful. You can mix and match, grep and this. So it's good to have this power with you. If you use -s, you can search through the change itself.

[00:07:06]
So there's a lot of cool opportunities here with log. Just so you guys know, it does exist.