¿Por qué la modificación de anulación de git cherry-pick en la rama actual no es suya si es diferente?

Mire, hago una modificación en una rama y luego elijo una confirmación de una rama similar, que no tiene esta modificación. Me pregunto si la modificación debe revertirse o no.

Inicialmente, las ramas A y B tienen una copia completa del mismo archivo

begin
 123
 456
 def f
 789
 klm
end

Pero ellos divergen. Primero, se mueve Adef f al final del archivo, produciendo A refactorizado

begin
 123
 456
 789
 klm
end
def f

Ahora, si seleccionamos B encima de este A, se recupera el archivo original (def f está de vuelta en el medio del archivo). Esto está bien porque dije hacer esta pregunta una vez que me informaron queselección de cereza con-theirs produce una alternativa primordial a la selección de cerezas. B es 'su' versión del archivo y es lo que esperaba porque vemos que B gana de hecho: la única diferencia entre A y B está en el lugar de la refactorización A y se prefiere la versión B en este caso.

Sin embargo, comencé a hacer esta pregunta porque no siempre es así. Si agregamos un poco de cambio a B, por ejemplo, reescribe la primera línea del procedimiento, por ejemplo, 123 a222 (Etiqueto esta nueva versión de BC en el código bash a continuación), ¿cuál será el resultado de elegir esta C en A? El resultado de elegir A <- C es desconcertante

begin
 222
 456
 789
 klm
end
def f

Usted ve, la primera línea es 222 de C perodef f también está al final, lo que significa que la refactorización de A se ha conservado y C no la ha anulado. Ese es un misterio de comportamiento inconsistente IMO. Cree que B es diferente de A en todo el archivo, pero no lo es, una vez que modifica un poco más. El cambio no relacionado detiene la reversión o simplemente no puedo entender las reglas de git. ¿Qué cambios debo esperar en la operación de selección de cereza?

pienso quees una situación relacionada donde la selección B indica que todo el archivo ha cambiado, mientras que si elige C modificado, la diferencia continúa por normal, detectando solo el cambio de una sola línea.

Puedes reconstruir la situación usando

mkdir preserving ; cd preserving
git init ; echo rrr > root
git add root ; git commit -m root

git checkout -b B ; git checkout -b A

function makeABC {
    echo begin > abc
    echo " 123" >> abc
    echo " 456" >> abc
    echo " def f" >> abc
    echo " 789" >> abc
    echo " klm" >> abc
    echo end >> abc
}

echo commiting ABC into branch A
makeABC ; git add abc ; git commit -m abc

echo refactoring A, def f moved into the end of file
git checkout A
sed -i -e '/def f/d' abc
echo "def f" >> abc
git add abc ; git commit -m "refactoring 'def f'"

echo posting abc into B
git checkout B ; makeABC ; git add abc ; git commit -m "abc in B"

echo choosing which branch to pick
picking="B" ; case $picking in
    "B") ;;
    "C") git checkout -b C ; sed -i -e 's/123/CCC/g' abc
        git add abc ; git commit -m CCC ;;
esac

git checkout A ; git cherry-pick $picking -Xtheirs 

echo observe if refactoring def f is in place in A
gitk --all & 

echo 'preserving' folder created

Establecer valor depicking variable a "B" o "C" para elegir la rama que desea elegir sobre A.

Respuestas a la pregunta(2)

Su respuesta a la pregunta