Inspector de parches y diffs
Toma un diff unificado —pegado, o un archivo .patch de git format-patch, de una URL .patch de GitHub o de una lista de correo— y te dice lo que hace antes de que lo apliques. Obtienes el asunto, el autor y la fecha del commit cuando el parche lleva cabecera de correo, y después una tabla por archivo: la ruta, si el archivo se añade, se elimina, se modifica, se renombra, cambia de modo o es binario, y el número exacto de líneas añadidas y eliminadas, contadas como las cuenta git. Lo importante es la parte que responde a la pregunta que de verdad tienes: si esto se aplicará limpiamente. Un diff unificado se describe a sí mismo: cada cabecera de hunk dice cuántas líneas cubre en cada lado, como en @@ -1,4 +1,5 @@, y git comprueba el cuerpo contra esa afirmación antes de tocar nada. Cuando ambos no coinciden —porque un cliente de correo volvió a ajustar una línea, porque alguien editó el parche a mano, o porque una línea de contexto perdió su espacio inicial por el camino— git se niega con `corrupt patch at line N` y ninguna explicación de lo que esperaba. Esta herramienta hace la misma aritmética y te muestra el hunk, lo que su cabecera prometía y lo que su cuerpo contiene de verdad. También señala los fallos más silenciosos: finales de línea CRLF que no casarán con archivos LF, líneas añadidas con espacios al final que un hook de pre-commit rechazará, un salto de línea final ausente, y una cabecera de archivo sin ningún hunk. Todo se ejecuta en tu navegador: el parche nunca se sube.
| Ruta | Cambio | Añadidas | Eliminadas | hunks |
|---|---|---|---|---|
| src/app.js | modificado | +2 | −1 | 1 |
| README.md | añadido | +2 | — | 1 |
Cómo usar
- Pega un diff unificado en la caja, o suelta encima un archivo .patch o .diff.
- Lee los totales para ver el tamaño del cambio: archivos tocados, inserciones, eliminaciones y número de hunks.
- Recorre la tabla buscando los archivos que te interesan; los renombrados muestran la ruta antigua junto a la nueva.
- Revisa lo resaltado en ámbar antes de ejecutar git apply: son las razones por las que fallaría.
- Para un parche llegado por correo, compara el aviso del hunk con `git apply --check`, que informa de la misma corrupción con menos detalle.
Preguntas frecuentes
- ¿Qué significa realmente `corrupt patch at line N`?
- Significa que el cuerpo del hunk no contenía el número de líneas que declaraba su cabecera. Una cabecera como @@ -1,4 +1,5 @@ promete cuatro líneas en el lado antiguo (contexto más eliminaciones) y cinco en el nuevo (contexto más adiciones). git cuenta mientras lee y se detiene en cuanto la aritmética se rompe, informando de la línea a la que llegó y no de la cabecera que estaba mal. Casi siempre la causa es el transporte: un cliente de correo ajustó una línea larga, o quitó el único espacio inicial que marca una línea de contexto, y un lado se queda corto. Esta herramienta indica el hunk, las cuentas que prometía y las que entregó, que normalmente basta para arreglarlo a mano.
- ¿Por qué las líneas de contexto en blanco rompen tantos parches?
- Porque una línea de contexto se marca con un único espacio inicial, así que una línea en blanco sin cambios acaba siendo una línea formada por exactamente un espacio. Eso es invisible, y muchísimas herramientas lo recortan: editores que quitan los espacios finales al guardar, clientes de correo, aplicaciones de chat, copiar y pegar a través de un terminal. En cuanto el espacio desaparece, la línea se lee como vacía en lugar de como contexto, y al hunk le falta una línea en ambos lados. Es la forma más común de que un parche que se veía bien en pantalla no se aplique.
- ¿Esta herramienta aplica el parche o lo comprueba contra mis archivos?
- No, y no puede. Lee el parche en sí —la aritmética dentro del diff— sin acceso a los archivos a los que apunta. Eso basta para detectar un parche corrupto o estropeado, que es una propiedad del parche por sí solo. No puede decirte si las líneas de contexto casan con tu árbol de trabajo, así que un parche que aquí sale bien formado todavía puede ser rechazado con `does not apply` si el archivo ha cambiado. Para esa comprobación hacen falta los archivos, y el comando es `git apply --check`.
- ¿Puede leer una salida de `diff -u` además de un parche de git?
- Sí. Un parche de git añade la línea `diff --git`, la línea index, los metadatos de renombrado y modo y —desde git format-patch— una cabecera de correo, y todo eso se lee cuando está presente. Un diff unificado simple de diff -u no tiene nada de eso: empieza directamente con un par de cabeceras `--- ` / `+++ `, y se trata igual. Los renombrados y los cambios de modo sencillamente no pueden detectarse en la forma simple, porque el formato no tiene manera de expresarlos.
- ¿Por qué el recuento de líneas difiere del que muestra GitHub?
- La vista de archivos de GitHub cuenta las mismas líneas, pero su resumen a veces difiere porque oculta archivos generados, colapsa diffs grandes y excluye los binarios de los totales. Esta herramienta cuenta todos los hunks del parche que le diste, que es el mismo número que informa `git apply --numstat`. Si los totales difieren, comprueba si el parche que tienes es el cambio completo: una URL .patch de un solo commit no coincidirá con el diff acumulado de un pull request.
- ¿Se sube mi parche a algún sitio?
- No. El texto lo analiza JavaScript en esta página y no se envía a ninguna parte; lo mismo vale para un archivo soltado, que se lee con la API de ficheros del navegador. Puedes confirmarlo cargando la página, desconectándote de la red y pegando un diff: sigue funcionando. Conviene saberlo, porque un parche suele ser lo más sensible de una revisión: contiene código sin publicar, entero.
Herramientas relacionadas
Constructor de JSON Patch (RFC 6902)
Genera un JSON Patch RFC 6902 desde un par source/target, o aplica un patch existente a un documento. Soporta ops add, remove, replace, move, copy, test.
Visor de Diferencias de Texto
Compara dos textos y ve adiciones y eliminaciones línea por línea o palabra por palabra.
Probador de .gitignore
Pega un .gitignore y una lista de rutas: verás cuáles se ignoran y qué línea lo decidió, igual que responde git check-ignore -v.
Herramientas Semver (Parser, Comparador, Incremento)
Parsea, compara e incrementa versiones semánticas lado a lado, con un expansor de rango que muestra qué cubren realmente ^x.y.z y ~x.y.z.
Generador de mensajes Conventional Commits
Crea un mensaje de Conventional Commits con tipo, alcance, cambio incompatible y pies, en tu navegador.
Generador de .gitignore
Marca lenguajes, frameworks, editores y sistemas operativos que usas — obtén un `.gitignore` combinado listo para soltar en un repo nuevo.