Tecnología · GUÍA PRÁCTICA
¿Git dice que el cherry-pick está vacío? Revisa el índice antes de omitirlo
Un commit propuesto sin cambios no demuestra que el árbol esté limpio ni que la corrección esté entregada. Seis pruebas desechables muestran qué revisar antes de elegir skip, keep o drop.
Un cherry-pick vacío puede indicar un cambio ya presente, un marcador creado vacío a propósito o una resolución de conflictos sin diferencia preparada. El mensaje por sí solo no identifica cuál de estos casos tienes.
Nuestro experimento con Git 2.51.1 también produjo el aviso mientras una edición necesaria seguía sin preparar. Separa primero el commit propuesto del árbol de trabajo y decide después si omitir o registrar el cambio actual.
Lee la operación y ambas diferencias
Ejecuta git status, git --version, git diff --cached y git diff. La diferencia cached compara el commit propuesto con HEAD; la normal compara el árbol de trabajo con el índice. Inspecciona también archivos sin seguimiento. Una diferencia cached vacía no elimina una diferencia normal con contenido.
Confirma si status indica cherry-pick o rebase. Rebase puede reproducir commits y mostrar internamente la expresión cherry-pick; usa los comandos de la operación real. No borres archivos del secuenciador ni ejecutes reset --hard para suprimir el aviso.
Identifica por qué queda vacío el cambio propuesto
Para un commit normal de un solo padre, inspecciona git show COMMIT y compara su cambio con el destino y la resolución prevista. El contenido ya presente y resolver totalmente un conflicto a favor del destino pueden dejar la misma ausencia de diferencia preparada, pero no demuestran la misma intención. Los commits de fusión necesitan una elección deliberada del padre principal.
El tutorial de Tower explica que cherry-pick aplica la diferencia de un commit, no copia toda su instantánea. También exige preparar los archivos resueltos antes de continuar. Si la resolución necesaria solo está en el árbol, revísala, prepara las rutas exactas y vuelve a inspeccionar la diferencia cached.
Elige una política para este estado
En un cherry-pick detenido, --skip omite el commit actual y continúa la secuencia restante. Úsalo solo tras confirmar que quieres descartar ese commit propuesto. Si necesitas un marcador histórico vacío, inspecciona primero el índice, ejecuta el git commit --allow-empty sugerido y sigue status para continuar lo pendiente.
En una ejecución nueva, --empty=drop gestiona cambios que se vuelven redundantes; --empty=keep los conserva e implica --allow-empty. --allow-empty por sí solo conserva commits originalmente vacíos, no todos los picks redundantes. A la inversa, --empty=drop solo no acepta un marcador originalmente vacío. En Git antiguo, consulta la ayuda instalada antes de depender de estas opciones.
Qué mostraron las seis pruebas desechables
Usamos repositorios temporales separados con Git 2.51.1, sin remotos ni repositorios del usuario. Para un parche no vacío ya aplicado, drop terminó sin mover HEAD; keep creó un commit vacío; --allow-empty solo siguió deteniéndose. Un commit inicialmente vacío también se detuvo con --empty=drop. Son distinciones ya documentadas por Git.
En una secuencia de dos commits, omitir el primero redundante aplicó el archivo posterior y eliminó CHERRY_PICK_HEAD. En el caso de conflicto preparamos la versión de destino y después dejamos una edición necesaria sin preparar. --continue informó de un pick vacío. --skip terminó y conservó la edición sin preparar, pero no la entregó en un commit. Es un caso sintético, no una promesa de que cualquier skip conserva todos los cambios locales.
Verifica la entrega, no solo que desaparezca el aviso
Tras la acción elegida, vuelve a leer status, el log pertinente y ambas diferencias. Confirma la corrección en los archivos resultantes, ejecuta su prueba significativa y comprueba que acabó la secuencia restante. Un árbol limpio, un marcador vacío y un comando exitoso responden preguntas diferentes. No hagas push solo porque desapareció el aviso.
El manual actual y las respuestas comunitarias actualizadas ya explican keep/drop/stop. Añadimos una auditoría ejecutada de ambas diferencias que revela una resolución sin preparar bajo el mensaje vacío. Un informe histórico de la interfaz de Fork se cerró en 2022 y tiene un comentario de recurrencia de 2026 sin versión; acredita demanda cualitativa, no que todas las versiones actuales estén averiadas.
