 you have a project where you have commits to a one commit, one commit, one commit, like that you have let's say some 50 commits. So now this is commit number one, this is commit number n. Okay, you notice that the nth commit has a bug and you know that commit number one does not have a bug. You don't know where it was introduced, you want to find it. So how do you do that? I don't know where it was introduced. This is a bug. I don't know exactly where the code was introduced. Because it's changed so much. Let's say 1000 commits or something. What do you do? You don't know the commit. You want to find the commit. Start with one commit, reset the commit. No, I don't know where it was introduced. This was a byproduct of something which my tests will catch. This is true. Are you going to faster like a byproduct? Yes, I'm fast. No, I don't know where the bug was introduced. Like somewhere between one and n, this bug was introduced. I don't know where. That's the problem. With git, you can use bisect. Bisect basically automates this process of one commit. You can tell him like this is the bad one. This is the good one. Find me the problem. You can figure it out for me. This is like really awesome. I'll show you a demo. That should drive out the point. Let's create a simple project. This was stolen by Mercurial and others. Let's say bisect demo. Get in it. Clean repository with nothing. I'm going to create a file called trial0.c and I have something include as you can see. It's a simple C program that just prints hello. I'm going to get at trial0.c. What I'm going to do is I'm going to add some commits. Let's say 20 commits. So now I have a situation where I have one initial commit and 20 commits. Now I'm trying to do this. It's artificial. Let's take this file once again and I make a mistake in this. If I try to compile this now, you do fail. And let's say we add this and we say git commit minus n. This is the commit that we're supposed to compile. And now we'll add some more. How many do you want? 100? If you have a commit message like that. That's the demo. So now we're at what? Git log minus 1.9. This is the history of the project. We have so many commits. How many are there? 123 commits. Now I try typing this and I say, it's not working. Yeah, who broke it? Somewhere in these 123 commits it broke. The question is to find which one. So what do I do? I say git log minus 1.9 and I go all the way down. The initial commit is here. As we read our text is here. You can temporarily check out like this. You get it to what's called a detached head state. Detached head state means usually what does head point to? It points to another reference, which points to a commit. If you check out directly to a commit, head will directly point to that commit. It's not attached to another actual reference. So if I make some commit over here it will come but there's no way to reach that. You can do this if you don't want to actually do any work or if you just want to see that commit. It's called detached head. So let's say I try typing this here. It works. So I know that this commit is good. And I go to master, git check out master. And I say I know that master is bad and this is good. This is good and master is bad. So what you can do is you can say git bisect start and you can give the bad commit. What is the bad commit? Master and the good commit. So it's saying start bisecting. Bisect means do a binary search between master and this. Master is the bad commit and this is the good commit. Somewhere in between there will be one commit where the failure first occurs. Find that from it. So let's do this. So it does something and it says it bisects at 60 revisions. It's gone halfway. And it's asking you. It's taken you to some commit. So it's asking you whether it's good or bad. So you type something that gcc tries and it breaks. So you say git bisect bad. So it goes somewhere else. And you again try gcc tries and it's still bad. So I say git bisect bad. Again it goes. This is good. So I say git bisect good. Try it again. It's git bisect bad. Try it again. This is good. So I say git bisect good. I say git. I'll say gcc tries 0.c. It's good. So I say git bisect good. Now I say gcc tries 0.c. It breaks. So I say git bisect bad. Okay. Fine. So you can do it like this. Okay. As if this wasn't enough. All right. As if this wasn't enough. What they do is they say git bisect. Git bisect. Start. You can say this. Start. And then you can say git. Get the example. You can say git bisect run. And the test is gcc tries 0.c. It'll actually do this for you automatically and find it. Just do it once again. So you just like this thing. We say git bisect start. Now the thing is I have an automated test to check whether this commit is good or bad. So then there's no need for me to actually manually run it each time. You tell git, this is the test. You figure out the bad commit for me. If you tell me the place where this is failing. So you say git bisect run. And the test is gcc tries 0.c. So 123 commits. It found exactly where the bad commit is. So there's two things to be said. One thing, you should have good tests. If you have good tests, you can pick up stuff like this very easily. Second thing, this is one big advantage of having all the data located. If this was subversion, now go over. You want to go back to a previous repository, fetch from the server. Come back here, fetch from the server. Return right, return right. gcc can return non-zero or fail. Most of your extents fail. Git bisect run. And the test. So gcc can enable the command file when you're out. It's awesome, no? If it fails, then it finds a 0. So if any command which returns a non-zero value is failure. What is the value of this? Non-zero is failure. No, non-zero is failure. Zero means success. So this slash bin, slash two, which is do nothing successful. And this slash bin, slash false, which is do nothing unsuccessful. So it doesn't do anything, but it returns 0, which means it's true. All right, so that's bisect.