git cherry-pick no funciona

110

Estoy tratando de seleccionar una confirmación del maestro y llevarla a la rama de producción actual. Sin embargo, cuando ejecuto git cherry-pick <SHA-hash>, recibo este mensaje:

# On branch prod_20110801
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#   site/test-result/
 nothing added to commit but untracked files present (use "git add" to track)
 The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

Otherwise, please use 'git reset'

Nota: Intenté hacer un reinicio y un reinicio --hard HEAD ^, y ninguno pareció cambiar nada.

Estoy confundido en cuanto a por qué esto no funciona para mí.

¡Cualquier idea, consejo o idea sobre cómo resolver esto sería útil ~!

git branching-and-merging cherry-pick Jay Taylor
fuente
Esto sucedió conmigo cuando traté accidentalmente de elegir la confirmación incorrecta. A veces sucede cuando se usa gitk.
cst1992

Respuestas:

141

Git está resolviendo la elección selectiva como una operación no operativa: todos los cambios introducidos por esa confirmación han sido introducidos por alguna confirmación en su rama actual. (O eso es lo que piensa Git, de todos modos). Verifique que la confirmación que está seleccionando no se haya fusionado ya de alguna manera, ya sea como una combinación adecuada, rebase / selección selectiva o parche por partes. (Use git show <commit-id>para ver la diferencia)

cdhowie
fuente
16
Gracias por tu consejo, resulta que la selección ya se había realizado y todo lo que tenía que hacer era enviarlo a github.
Jay Taylor
Bien, no me di cuenta de que estaba verificando el contenido de los archivos con el ID de confirmación. Fui a buscar el ID de confirmación en el registro y no pude encontrarlo. resultó que ya se había fusionado.
mparaz
Desafortunadamente, esta no es la única razón del problema en cuestión. Tengo exactamente la misma situación cuando tuve un compromiso, que revierte un compromiso anterior, y cuando lo seleccioné con precisión en otra rama, ¿qué historial no se habían revertido los cambios? (Es decir, no había elegido con precisión esa confirmación revertida ). Por supuesto, eso es culpa mía. Pero en este caso, se espera que git falle con un estado de conflicto, en lugar de intentar ser demasiado inteligente, lo que genera confusión en el usuario.
Artem Pisarenko
Esto podría suceder si revierte una confirmación de fusión y la confirmación que se va a seleccionar reside en la rama revertida.
Matt
11

En mi caso, esto me estaba volviendo loco, ya que era bastante obvio que la confirmación específica que quería seleccionar no se había fusionado con mi rama actual.

Resulta que alguien ya había elegido el compromiso una semana antes. Los cambios , pero no el SHA específico, ya estaban en mi rama actual y no los había notado.

Compruebe los archivos que está intentando seleccionar. Si ya tienen los cambios, una versión de la confirmación ya ha sido seleccionada o agregada de otra manera. Por lo tanto, no es necesario volver a recogerlo.

pkamb
fuente
Estoy bastante seguro de que la confirmación específica nunca está en su rama cuando fue traída por una selección de cereza, porque la selección de cerezas será un nuevo hash, ¿verdad? ¿O lo estoy entendiendo mal?
msouth
Lo @msouth Tomé originalmente lejos de otras respuestas era "la confirmación ya estaba fusionado", pero pude ver que era no en mi rama. Sin embargo, tienes razón en que Cherry Pick siempre es un nuevo SHA.
pkamb
Sí, estaba pensando "el compromiso específico, identificado por el hash", cuando escribí eso. Mi lenguaje era impreciso. A menudo miro hacia atrás a través de la salida de git log --graph --pretty --decorate --onelinepara ver si un SHA determinado está en mi rama o no. Vea mi respuesta a continuación sobre cómo también puede confundirse si piensa que el mensaje de confirmación es indicativo del cambio: hay una situación en la que no lo es, y eso es lo que me llevó a esta pregunta originalmente. El cerebro de uno tiende a tomar esos atajos y ocasionalmente pueden volver a morderlo.
msouth
6

También tenga en cuenta que agregar un archivo vacío (por ejemplo .gitkeep) al árbol es considerado por cherry-pick como una confirmación vacía.

Neamar
fuente
En mi caso, tuve un compromiso de reversión (que estaba revertiendo un compromiso vacío en sí mismo) antes de mi intento de selección selectiva, así que supongo que cualquier cosa vacía probablemente hará que aparezca este mensaje.
lidkxx
3

Entonces, aquí hay otra situación confusa en la que esto puede surgir: tuve lo siguiente:

captura de pantalla de git log

Estaba tratando de seleccionar 9a7b12e, que aparentemente no es nada; incluso trató de decirme en esa línea en la salida del registro de git que 4497428 era lo que realmente quería. (Lo que hice fue buscar el mensaje de confirmación y agarrar el primer hash que vi que lo tenía). De todos modos, solo quiero que la gente sepa que hay otra forma en que puedes ser engañado para intentar elegir una operación no.

msouth
fuente
10
No es muy útil para ti votar en contra sin explicación: esta es la reproducción exacta de un problema que tuve que me llevó a encontrar esta pregunta en mi búsqueda. Si tiene una recomendación para mejorar esto, por favor dígame en los comentarios en lugar de simplemente rechazarla.
msouth