Git Pickaxe: The git log -S Command for Tracking Deleted Code

⏱️ Lectura: 11 min

git log -S, nicknamed git pickaxe because it digs through history like someone excavating with a pickaxe, doesn’t show up in most Git tutorials. Yet it answers in seconds a question every developer asks when facing a bug in legacy code: which commit added, or removed, this exact line?

📑 En este artículo

1. TL;DR
2. Introduction
3. What Happened
4. Context and History
5. Technical Details: How git pickaxe Works
6. Getting Started
7. Impact and Analysis
8. What’s Next
9. Frequently Asked Questions
   1. What’s the difference between git log -S and searching with grep on each commit?
   2. Does git log -S work on binary files?
   3. Is EXPLAIN ANALYZE safe in production?
   4. Do I need to install anything to use SELECT without FROM?
   5. What does a team gain by sharing one technical trick a day?
10. References

Developer Will Keleher singled it out as the most useful item on a list of technical tricks that, in his view, save more time than learning a new framework. His post Small Programming Tricks, published on will-keleher.com, gathers Git, SQL, regex, and terminal shortcuts that few developers discover on their own.

TL;DR

• Will Keleher published Small Programming Tricks, a list of little-known commands that experienced developers use every day.
• The most cited trick is git log -S, nicknamed git pickaxe: it finds the exact commit where a string of text was added or removed.
• git log -G is the regular-expression variant: it also detects lines that moved without changing their content.
• PostgreSQL and MySQL support EXPLAIN ANALYZE, which runs the actual query and shows the exact time for each step of the plan.
• fzf turns your bash or zsh history into a fuzzy search when you press ctrl+r.
• Node.js reduces outbound request latency by reusing connections with an https.Agent configured with keepAlive.
• Modern JavaScript already includes Array.flatMap, Object.entries, and Promise.withResolvers with no external libraries.
• Bash and zsh let you replace find with recursive globs using shopt -s globstar, with nothing extra to install.

Introduction

Most programming courses teach languages, frameworks, and architectures. Few teach the terminal, SQL, and version control shortcuts that an experienced developer uses every day without a second thought. Keleher’s post gathers a dozen of these shortcuts, spanning databases, regular expressions, Node.js, and Git.

This article takes a deep dive into the list’s most cited trick, git pickaxe (git log -S), with runnable examples, and walks through the rest of the catalog with its practical application for teams maintaining code in production.

What Happened

Keleher’s post doesn’t announce a new tool or a launch: it’s a curated collection of scattered knowledge. His central argument is that an engineer’s productivity rarely comes from mastering an entire language, but from knowing dozens of specific tricks that solve a particular problem in seconds instead of minutes.

Among the examples he mentions are fuzzy history search with fzf, using SELECT without FROM in SQL, the EXPLAIN ANALYZE clause in Postgres and MySQL, the regular-expression word-boundary operator \b, logarithmic bucketing for metrics, new JavaScript functions (Array.flatMap, Object.entries, Promise.withResolvers), the Node.js https.Agent pattern for keeping connections alive, and several little-known Git commands like git log -S, git log -G, and git checkout -.

Context and History

The -S option of git log has existed since Git’s earliest days. Linus Torvalds designed the system in 2005 for Linux kernel development, where the history of thousands of files made it impossible to manually track when a given function appeared. The official git log documentation describes this search as pickaxe, because it lets you dig through history until you find the exact commit that introduced or removed a string of text.

Two decades later, it remains one of the least-known features of the world’s most widely used version control system. Most developers investigate legacy code by opening files one by one or using git blame, which only shows the last commit that touched each line currently visible, not the commit that deleted it.

Technical Details: How git pickaxe Works

git log -S and git log -G solve the same problem with different strategies. The first counts how many times an exact string appears in each version of the file and reports the commits where that count changed. The second accepts a regular expression and compares changes line by line, so it also detects lines that moved without altering the total number of occurrences.

git log -S'calcularDescuento' --oneline -- src/checkout.js

This command searches src/checkout.js for the commits where the number of occurrences of the string calcularDescuento changed: normally the commit where the function was added and, if it exists, the commit where it was removed.

git log -G'calcularDescuento\(.*\)' --oneline -- src/checkout.js

With -G and a regular expression, this command also detects whether someone moved the function to another part of the file without changing its signature, something -S can miss because the occurrence count doesn’t change.

flowchart TD
    A["git log -S 'text'"] --> B["Goes through each commit in history"]
    B --> C{"Did the occurrence count change?"}
    C -->|"Yes"| D["Commit included in the result"]
    C -->|"No"| E["Commit discarded"]

Option	When to Use It	Advantage	Limitation
git log -S	Find when an exact string was added or removed	Fast, precise results based on occurrence count	Doesn’t detect lines that moved without changing the count
git log -G	Search for patterns, refactors, or relocated lines	Also detects code reordering	Slower on large repositories since it evaluates a regex on every diff

💡 Tip: add -p to the end of the command (for example git log -S'calcularDescuento' -p -- src/checkout.js) to see the full diff of each commit found and confirm it isn’t a false positive.

Another trick from Keleher’s list is EXPLAIN ANALYZE, available in both PostgreSQL and MySQL. Unlike a plain EXPLAIN, which only estimates the execution plan without running the query, EXPLAIN ANALYZE runs the actual query and adds the measured time for each step.

EXPLAIN ANALYZE
SELECT usuario_id, COUNT(*)
FROM pedidos
WHERE creado_en > NOW() - INTERVAL '7 days'
GROUP BY usuario_id;

The result shows the actual plan, for example a Seq Scan or an Index Scan, along with the time in milliseconds for each node. If the Seq Scan over pedidos takes longer than expected, that measured time is the signal to create an index on creado_en.

⚠️ Heads up: EXPLAIN ANALYZE really runs the query, including INSERT, UPDATE, or DELETE. To test a write query without applying the changes, wrap it in a transaction: BEGIN; followed by the EXPLAIN ANALYZE and ROLLBACK; at the end.

Keleher also points out a little-known performance pattern in Node.js: reusing the TCP connection between outbound HTTP requests with an https.Agent configured to keep it alive.

const https = require('node:https');
const keepAliveAgent = new https.Agent({ keepAlive: true, maxSockets: 50 });

async function obtenerPedido(id) {
  const res = await fetch('https://api.tienda.interno/pedidos/' + id, {
    agent: keepAliveAgent,
  });
  return res.json();
}

Without this agent, every call to fetch opens a new TLS handshake against the same host. With keepAlive: true, subsequent requests reuse the socket that’s already open, which reduces latency in services that make many outbound calls to the same destination.

To confirm the connections are being reused, run the process with the NODE_DEBUG=http variable and check that the log shows reusedSocket: true on requests after the first one.

Getting Started

To try git log -S you don’t need to install anything extra: it comes included with any Git installation. The other tricks on the list do require installing specific tools.

# macOS (Homebrew)
brew install fzf

# Linux (Debian/Ubuntu)
sudo apt install fzf

# Windows (winget)
winget install fzf

After installing fzf, enable the ctrl+r integration by adding this to your .bashrc or .zshrc:

source /usr/share/doc/fzf/examples/key-bindings.bash
source /usr/share/doc/fzf/examples/completion.bash

On macOS with Homebrew, the fzf installer directly asks whether you want to enable these shortcuts in your shell.

To replace grep with ripgrep, which Keleher recommends for its speed on large repositories, the installation is similar:

# macOS
brew install ripgrep

# Linux (Debian/Ubuntu)
sudo apt install ripgrep

# Windows (winget)
winget install BurntSushi.ripgrep.MSVC

And to enable zsh’s advanced autocompletion, which isn’t turned on by default, add this to ~/.zshrc:

if type brew &>/dev/null; then
  FPATH="$(brew --prefix)/share/zsh/site-functions:${FPATH}"
fi
autoload -Uz compinit
compinit

Impact and Analysis

Keleher says that at a previous company he shared one trick a day in the engineering team’s Slack channel, mixing general techniques with company-specific knowledge: which data source to check to debug a given problem, who on the team is an expert in a given area, where the documentation for a given system lives. One trick a day turned out to be the right cadence to avoid overwhelming the team and, occasionally, spark a useful discussion.

The idea connects with a pattern that repeats in teams maintaining large, old systems: the cost of a bug rarely lies in writing the fix, but in finding where in the code and when the problem was introduced. Tools like git pickaxe turn an hours-long manual search, reviewing commit by commit, into a command that takes seconds.

For teams in Latin America that inherit legacy code from third parties or from developers no longer at the company, this kind of trick matters even more: documentation tends to be scarce, and Git history ends up being the only reliable source of context.

What’s Next

Keleher also mentions tools that extend the idea of fuzzy search into command history: atuin, which replaces shell history with an indexed SQLite database that can sync across machines, and per-directory-history, which lets you switch between searching commands run in a specific directory or across the entire history. Neither replaces fzf, but both solve a similar problem at a larger scale.

Keleher himself invites every developer to identify their own accumulated tricks and share them with their team, beyond the specific list in his post. The expectation isn’t that everyone knows the same tools, but that each team builds its own catalog of shortcuts specific to its stack and codebase.

Try it yourself: run git log -S'nombreDeFuncion' --oneline in any repository you maintain today and confirm in seconds which commit that function appeared in.

📖 Summary on Telegram: View summary

Frequently Asked Questions

What’s the difference between git log -S and searching with grep on each commit?

grep has no direct access to history: you’d need to iterate commit by commit with a script. git log -S performs that search internally and only returns the commits where the count of the searched string changed, which avoids manually reviewing hundreds of versions of the file.

Does git log -S work on binary files?

Not usefully. The -S search relies on comparing plain text between versions, so the result isn’t interpretable for binaries. It works best on source code, configuration files, and any text file.

Is EXPLAIN ANALYZE safe in production?

It’s safe for SELECT queries. For INSERT, UPDATE, or DELETE, run it inside a transaction with ROLLBACK at the end, because the command runs the actual query and can modify data if it isn’t rolled back.

Do I need to install anything to use SELECT without FROM?

No. It’s standard SQL syntax supported by PostgreSQL and MySQL: it’s useful for testing how a function or operator behaves, for example SELECT NOW() or SELECT 1 = 1, without needing to point to an actual table.

What does a team gain by sharing one technical trick a day?

Based on the experience Keleher describes, even if the team already knows nine out of every ten tricks shared, the tenth usually saves someone real time, and the daily cadence, no more and no less, keeps the channel from getting overloaded without losing the habit.

References

• Small Programming Tricks, by Will Keleher: the original post that compiles the tricks mentioned in this article.
• Official git log documentation: complete reference for the -S and -G (pickaxe) options.
• Official EXPLAIN documentation in PostgreSQL: details the difference between EXPLAIN and EXPLAIN ANALYZE.
• fzf repository on GitHub: installation and configuration of the command-line fuzzy finder.
• ripgrep repository on GitHub: documentation for the text search tool recommended as an alternative to grep.

📱 Enjoying this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.

Imagen destacada: Foto de RoonZ nl en Unsplash