What is Git Blame & it's usecases

Git Blame

Have you ever wondered who touched a bunch of lines in this code last time? There have been lot of situations which can leave people baffled for a while to know who actually changed what. Blame labels each line in the code with the details of the last revision that took place on that part of the file, including moving the line from one place to other.

Ideology behind the concept

When you study a code, a very large one. Like some parts of CPython repo. You will eventually find yourself at a stage where you do not understand what the code does there. Why is it there? Had it not been there would it affect the code in any manner? You need to guess it how it must have been used. But the author of that commit, the one who actually wrote it, must have known what he/she meant to do by introducing that tricky part. And that should be explained in the commit message that the person must have written. Here's when git blame plays it's card (also pickaxe, discussed later), and helps the user to identify who actually did the last revision on that commit. Also, it can easily help to seek an individual who is responsible for the current state of the code and hence can be blamed if the code breaks there.

To check it out, the simplest way is:

git blame <filename>

This will give you result in the format

(Short commit hash)  (Author's name  Date  Time  UTC-Time-Offset  Line-Number)

The actual line goes in front of these.

Refactoring Code

It's the process referring to rearranging different parts of an already existing program to make it more readable. It also includes adding or modifying a part without changing the ultimate objective it was created to serve. That means in code refactoring you can modify a piece of code to make it more readable, given that you do not change what it was supposed to do. Which sometimes not only makes it look more appealing but also enables one to be able to see hidden bugs. One very interesting term named code smell is also used in the similar sense sometimes. It means the sense that certain part of the code indicates a deeper problem. Though it may work, it is a weak point to the code, which can be dealt with decomposition (breaking a large problem into smaller pieces that are more understandable) and then refactor it.

But blame shows the last revision, so when a code piece is refactored, what happens is, the blame changes to the person who did the movement of the line from one place to other for the readability's sake. This is both good and bad.

Good because, if the code breaks due to improper refactoring, then the person responsible can be identified. It is very necessary to identify such person if the improper refactoring was intentional and was an attempt to hamper the project. But mostly this is not the case, since tests in the project repo breaks in most of the projects. From this comes the bad part. If the line moved or copied is blamed to the person refactoring the code, then it's almost useless. You cannot understand why the line was placed there seeing a refactoring commit.

This problem can be solved by the pickaxe.

Pickaxe

Pickaxe is not a new command. It's just git log with -S argument. But it's not the syntax what's interesting. It's what pickaxe is capable of doing. It searches for a commit where a string was added or removed. And so you can easily reach to the actual author of the commit.

It's syntax is:

git log -S <search-string> [path/file]

Another preferred way is to use -p option simultaneously which will also generate a patch or a diff of the commit. It's then easier to see what change took place in which commit.

git log -p -S <search-string> [path/file]

In this, you can also specify the filename in which to search this specific string, but it loses when the filename is changed in a commit. So at times, it's better not to specify the filename and search among the results that are displayed.

Git blame comes with GUI for Tcl/Tk based interface versions, where it does both pickaxe and blame together! It lists the original commits, (the ones which created the said line), and the latest commit on that line including moving and copying it from one place to another in the file. You can further explore more on this.

If you've any questions, please feel free to ask in the comments section below.