¿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.