Git Blame Can Do More


Hi Friends,

Today, we’re diving into the often under-appreciated git blame.

Often used to find out who last modified a line of code, git blame has several powerful features. Let’s explore some of these hidden gems, particularly focusing on the flags:

  • -w
  • -C
  • -C -C
  • -C -C -C

Ignoring Whitespace with the -w Flag

Do you know the annoying blame results showing over an indent or a space removed / added?
"-w" fixes that!

git blame -w file_name

And you got yourself a clean blame with the real authors of changes.

Ignoring Code Movements With -C Flag

The -C flag takes it a step further. It detects lines that were copied or moved from other files in the repository!
This is particularly useful in large projects where code refactoring and file splitting or merging are common:

git blame -C file_name

To extend the detective work, using -C -C instructs Git to examine not just the target blame file but also to look at other potential sources in the repository:

git blame -C -C file_name

The double -C makes git blame even more robust against file shifts and reorganizations, tracking down code origins through multiple levels of file history.

Maximum Traceability with -C -C -C

Finally, -C -C -C expands the search scope to its maximum:

git blame -C -C -C file_name

Triple -C helps in scenarios where significant portions of a codebase have been moved around multiple times, potentially across multiple files over an extended period. It ensures that you can trace back to the initial commits affecting the current state of any line of code.


git blame is more than just a tool for finding who wrote a line of code; it’s a gateway to the history and evolution of your project. I’ve been using it extensively recently and learned a lot about changes made over periods of time.

Since many code changes are 'obfuscated' over time because of small changes, formatters, and re-orgs, we're left with a hard-to-follow chain of events. Knowing how to remove these layers has been super helpful trying to understand code authors and why/how things were done.

Thanks for reading, have a great weekend!

Whenever you’re ready, here’s how I can help you

ESPRESSO FRIDAYS

Every once in a while I send hand picked things I've learned. Kind of like your filter to the tech internet. No spam, I promise!

Read more from ESPRESSO FRIDAYS

7 Amazing API Tools You Need To Try Before becoming a systems architect working with unicorns, I made a mistake that cost my team three days of debugging. I hardly left the office for 48 hours, and that experience taught me a valuable lesson. I thought I knew everything about HTTP requests. Having used curl for years, writing APIs, and building integrations, I felt confident. Then came the incident Our back-office application was failing, and we couldn’t help with burning customer requests. I...

Stop Using Docker. Use Open Source Instead. You know how people say "Google it" to describe any online search? Well, the same thing happened with Docker - it became synonymous with containers. But times are changing, and your wallet (and lawyer?) might thank you for paying attention, especially if you're using Docker for commercial purposes. Four years ago, Docker made a move that shocked the container world, everyone saw it coming from miles away, but ignored it, until it became real - they...

This Neovim "Plugin" Replaces 40 Others You know the feeling of finding a new improvement to your setup that you KNOW is going to change it completely? "Imagine living your entire life carrying heavy loads on your back dragging things through the road thinking: `well that's just how it is`" - Homo sapiens, before the invention of the wheel That's exactly what coding without mini.nvim feels like once you've experienced its power, especially if you're Neovim setup was closer to vanilla. Will...