Git log -S: el comando pickaxe que rastrea código borrado en tu repo

git log -S, apodado git pickaxe por buscar en el historial como quien excava con un pico, no aparece en la mayoría de los tutoriales de Git. Sin embargo resuelve en segundos una pregunta que cualquier desarrollador se hace frente a un bug en código legado: ¿en qué commit se agregó, o se borró, esta línea exacta?

El desarrollador Will Keleher lo destacó como el más útil de una lista de trucos técnicos que, según él, ahorran más tiempo que aprender un framework nuevo. Su post Small Programming Tricks, publicado en will-keleher.com, reúne atajos de Git, SQL, regex y terminal que pocos desarrolladores descubren por su cuenta.

TL;DR

• Will Keleher publicó Small Programming Tricks, una lista de comandos poco conocidos que usan a diario desarrolladores con experiencia.- El truco más citado es git log -S, apodado git pickaxe: busca el commit exacto donde se agregó o borró una cadena de texto.- git log -G es la variante con expresiones regulares: también detecta líneas que se movieron de lugar sin cambiar su contenido.- PostgreSQL y MySQL soportan EXPLAIN ANALYZE, que ejecuta la consulta real y muestra el tiempo exacto de cada paso del plan.- fzf convierte el historial de bash o zsh en una búsqueda difusa al presionar ctrl+r.- Node.js reduce la latencia de peticiones salientes reutilizando conexiones con un https.Agent configurado con keepAlive.- JavaScript moderno ya incluye Array.flatMap, Object.entries y Promise.withResolvers sin librerías externas.- Bash y zsh permiten reemplazar find por globs recursivos con shopt -s globstar, sin instalar nada adicional.

Introducción

La mayoría de los cursos de programación enseñan lenguajes, frameworks y arquitecturas. Pocos enseñan los atajos de terminal, SQL y control de versiones que un desarrollador con experiencia usa todos los días sin pensarlo dos veces. El post de Keleher reúne una docena de esos atajos, desde bases de datos hasta expresiones regulares, pasando por Node.js y Git.

Este artículo profundiza en el truco más citado de la lista, git pickaxe (git log -S), con ejemplos ejecutables, y repasa el resto del catálogo con su aplicación práctica para equipos que mantienen código en producción.

Qué pasó

El post de Keleher no anuncia una herramienta nueva ni un lanzamiento: es una recopilación curada de conocimiento disperso. Su argumento central es que la productividad de un ingeniero rara vez viene de dominar un lenguaje completo, sino de conocer decenas de trucos puntuales que resuelven un problema específico en segundos en lugar de minutos.

Entre los ejemplos que menciona están la búsqueda difusa de historial con fzf, el uso de SELECT sin FROM en SQL, la cláusula EXPLAIN ANALYZE de Postgres y MySQL, el operador \b de expresiones regulares para delimitar palabras, el bucketing logarítmico para métricas, las funciones nuevas de JavaScript (Array.flatMap, Object.entries, Promise.withResolvers), el patrón https.Agent de Node.js para mantener conexiones vivas, y varios comandos de Git poco conocidos como git log -S, git log -G y git checkout -.

Contexto e historia

La opción -S de git log existe desde los orígenes de Git. Linus Torvalds diseñó el sistema en 2005 para el desarrollo del kernel de Linux, donde el historial de miles de archivos hacía inviable rastrear a mano cuándo apareció una función determinada. La documentación oficial de git log describe esta búsqueda como pickaxe, porque permite cavar en el historial hasta encontrar el commit exacto que introdujo o eliminó una cadena de texto.

Dos décadas después, sigue siendo una de las funciones menos conocidas del sistema de control de versiones más usado del mundo. La mayoría de los desarrolladores investiga código legado abriendo archivo por archivo o usando git blame, que solo muestra el último commit que tocó cada línea visible hoy, no el commit que la eliminó.
La opción -S de git log existe desde 2005, cuando Torvalds creó Git.

Detalles técnicos: cómo funciona git pickaxe

git log -S y git log -G resuelven el mismo problema con estrategias distintas. La primera cuenta cuántas veces aparece una cadena exacta en cada versión del archivo y reporta los commits donde ese conteo cambió. La segunda acepta una expresión regular y compara los cambios línea por línea, por lo que también detecta líneas que se movieron de lugar sin alterar el número total de apariciones.

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

Este comando busca en src/checkout.js los commits donde cambió el número de apariciones de la cadena calcularDescuento: normalmente el commit donde se agregó la función y, si existe, el commit donde se eliminó.

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

Con -G y una expresión regular, este comando también detecta si alguien movió la función a otra parte del archivo sin cambiar su firma, algo que -S puede pasar por alto porque el conteo de apariciones no varía.

flowchart TD
    A["git log -S 'texto'"] --> B["Recorre cada commit del historial"]
    B --> C{"Cambio el numero de apariciones?"}
    C -->|"Si"| D["Commit incluido en el resultado"]
    C -->|"No"| E["Commit descartado"]

OpciónCuándo usarlaVentajaLimitacióngit log -SBuscar cuándo se agregó o borró una cadena exactaRápida, resultados precisos por conteo de ocurrenciasNo detecta líneas que se movieron sin cambiar el conteogit log -GBuscar patrones, refactors o líneas reubicadasDetecta también reordenamientos de códigoMás lenta en repositorios grandes por evaluar una regex en cada diff

💡 Tip: agregá -p al final del comando (por ejemplo git log -S'calcularDescuento' -p -- src/checkout.js) para ver el diff completo de cada commit encontrado y confirmar que no es un falso positivo.

Otro truco de la lista de Keleher es EXPLAIN ANALYZE, disponible tanto en PostgreSQL como en MySQL. A diferencia de un EXPLAIN simple, que solo estima el plan de ejecución sin correr la consulta, EXPLAIN ANALYZE ejecuta la consulta real y agrega el tiempo medido de cada paso.

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

El resultado muestra el plan real, por ejemplo un Seq Scan o un Index Scan, junto con el tiempo en milisegundos de cada nodo. Si el Seq Scan sobre pedidos tarda más de lo esperado, ese tiempo medido es la señal para crear un índice sobre creado_en.

⚠️ Ojo: EXPLAIN ANALYZE ejecuta la consulta de verdad, incluyendo INSERT, UPDATE o DELETE. Para probar una consulta de escritura sin aplicar los cambios, envolvela en una transacción: BEGIN; seguido del EXPLAIN ANALYZE y ROLLBACK; al final.

Keleher también señala un patrón de rendimiento poco conocido en Node.js: reutilizar la conexión TCP entre peticiones HTTP salientes con un https.Agent configurado para mantenerla viva.

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();
}

Sin este agente, cada llamada a fetch abre un handshake TLS nuevo contra el mismo host. Con keepAlive: true, las peticiones siguientes reutilizan el socket ya abierto, lo que reduce la latencia en servicios que hacen muchas llamadas salientes al mismo destino.

Para confirmar que las conexiones se están reutilizando, corré el proceso con la variable NODE_DEBUG=http y revisá que el log muestre reusedSocket: true en las peticiones posteriores a la primera.
EXPLAIN ANALYZE ejecuta la consulta real, no solo estima su plan.

Cómo empezar

Para probar git log -S no hace falta instalar nada adicional: viene incluido en cualquier instalación de Git. Los otros trucos de la lista sí requieren instalar herramientas puntuales.

# macOS (Homebrew)
brew install fzf

# Linux (Debian/Ubuntu)
sudo apt install fzf

# Windows (winget)
winget install fzf

Después de instalar fzf, activá la integración con ctrl+r agregando a tu .bashrc o .zshrc:

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

En macOS con Homebrew, el instalador de fzf pregunta directamente si querés habilitar estos atajos en tu shell.

Para reemplazar grep por ripgrep, que Keleher recomienda por su velocidad en repositorios grandes, la instalación es similar:

# macOS
brew install ripgrep

# Linux (Debian/Ubuntu)
sudo apt install ripgrep

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

Y para activar el autocompletado avanzado de zsh, que no viene encendido por defecto, agregá esto a ~/.zshrc:

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

Impacto y análisis

Keleher cuenta que en una empresa anterior compartía un truco por día en el canal de Slack del equipo de ingeniería, mezclando técnicas generales con conocimiento específico de esa compañía: a qué fuente de datos recurrir para depurar tal problema, quién en el equipo domina tal área, dónde está la documentación de tal sistema. Un truco al día resultó ser la cadencia justa para no saturar al equipo y, ocasionalmente, disparar una discusión útil.

La idea conecta con un patrón que se repite en equipos que mantienen sistemas grandes y antiguos: el costo de un bug rara vez está en escribir la solución, sino en encontrar en qué parte del código y en qué momento se introdujo el problema. Herramientas como git pickaxe convierten una búsqueda manual de horas, revisando commit por commit, en un comando de segundos.

Para equipos en Latinoamérica que heredan código legado de terceros o de desarrolladores que ya no están en la empresa, este tipo de trucos importa todavía más: la documentación suele ser escasa y el historial de Git termina siendo la única fuente confiable de contexto.

Qué sigue

Keleher menciona además herramientas que amplían la idea de búsqueda difusa en el historial de comandos: atuin, que reemplaza el historial de la shell por una base de datos SQLite indexada y sincronizable entre máquinas, y per-directory-history, que permite alternar entre buscar comandos ejecutados en un directorio específico o en todo el historial. Ninguna de las dos reemplaza a fzf, pero ambas resuelven un problema similar a mayor escala.

El propio Keleher invita a que cada desarrollador identifique sus propios trucos acumulados y los comparta con su equipo, más allá de la lista puntual de su post. La expectativa no es que todos conozcan las mismas herramientas, sino que cada equipo construya su propio catálogo de atajos específicos de su stack y su base de código.

Probalo vos: corré git log -S'nombreDeFuncion' --oneline en cualquier repositorio que mantengas hoy mismo y confirmá en segundos en qué commit apareció esa función.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué diferencia hay entre git log -S y buscar con grep en cada commit?

grep no tiene acceso directo al historial: habría que recorrer commit por commit con un script. git log -S hace esa búsqueda internamente y solo devuelve los commits donde cambió el conteo de la cadena buscada, lo que evita revisar manualmente cientos de versiones del archivo.

¿git log -S funciona en archivos binarios?

No de forma útil. La búsqueda de -S depende de comparar texto plano entre versiones, así que en binarios el resultado no es interpretable. Funciona mejor en código fuente, configuración y cualquier archivo de texto.

¿EXPLAIN ANALYZE es seguro en producción?

Es seguro para consultas SELECT. Para INSERT, UPDATE o DELETE, ejecutalo dentro de una transacción con ROLLBACK al final, porque el comando corre la consulta real y puede modificar datos si no se revierte.

¿Necesito instalar algo para usar SELECT sin FROM?

No. Es sintaxis estándar de SQL soportada por PostgreSQL y MySQL: sirve para probar cómo se comporta una función o un operador, por ejemplo SELECT NOW() o SELECT 1 = 1, sin necesidad de apuntar a una tabla real.

¿Qué gana un equipo compartiendo un truco técnico por día?

Según la experiencia que relata Keleher, incluso si el equipo ya conoce nueve de cada diez trucos compartidos, el décimo suele ahorrar tiempo real a alguien, y la cadencia diaria, ni más ni menos, evita saturar el canal sin perder la costumbre.

Referencias

• Small Programming Tricks, de Will Keleher: el post original que recopila los trucos mencionados en este artículo.- Documentación oficial de git log: referencia completa de las opciones -S y -G (pickaxe).- Documentación oficial de EXPLAIN en PostgreSQL: detalla la diferencia entre EXPLAIN y EXPLAIN ANALYZE.- Repositorio de fzf en GitHub: instalación y configuración del buscador difuso de línea de comandos.- Repositorio de ripgrep en GitHub: documentación del buscador de texto recomendado como alternativa a grep.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.