Cómo corregir problemas de revisión en Gerrit cuando hay una segunda revisión más reciente también

Question

Todavía estoy tratando de aprender a usar Gerrit y su proceso. Pasos que hicieron donde

1. empuje primera change1 a Gerrit para su revisión a CABEZA: refs/a/desarrollar
2. trabajar en otra cosa en la misma rama y empuje change2 a Gerrit para su revisión a CABEZA: refs/a/se desarrollan

Ambos han compromete Gerrit líneas de Cambio-ID

así que ahora quiero abordar problema para change1 así que no

git checkout -b change1 <change 1's commit id> 

hizo que mi cambios y comprometido (añadiendo el Cambio-ID para el mensaje de confirmación)

git add . 
git commit 

Ahora cuando hago

git push origin HEAD:refs/for/develop 

me sale

! [remote rejected] HEAD -> refs/for/develop (squash commits first) 
error: failed to push some refs to 'ssh://adrian@192.168.7.100:29418/CommunicationsLibrary' 

Cómo hacer Corrijo los problemas en las reseñas apiladas y lo publico en gerrit sin tener que crear otra revisión.

Answer 1

Cuando tiene revisiones dependientes en Gerrit (es decir, un cambio en la revisión que depende de un cambio anterior que se revisa simultáneamente), y necesita realizar modificaciones en el cambio anterior, debe volver a enviar ambos cambios (desde el segundo cambio se vuelve dependiente de un "padre" diferente comprometen)

Así que la situación es que tiene dos comete en una sola rama fuera de la rama principal de desarrollo, así:

o master 
\ 
o Commit A (in review, requires change) 
o Commit B (in review, no changes required) 

Lo que generalmente hago en esta situación es hacer los cambios solicitados del Compromiso A en un tercer compromiso. Nuestra cometer gráfico ahora se ve así:

o master 
\ 
o Commit A (in review, requires change) 
o Commit B (in review, no changes required) 
o Commit C (modifications to Commit A) 

Ahora voy a hacer git rebase -i master y reordenar Commit C a venir después de cometer un Commit pero antes de B, y luego aplastarlo en Commit A. El gráfico se comprometen ahora se ve así:

o master 
\ 
o Commit A' (Commit A, incorporating the changes from Commit C) 
o Commit B' (the same changes made in Commit B, but applied to Commit A' instead of A) 

Por último, git review (o cualquier comando que utiliza para enviar los cambios a Gerrit) para volver a presentar tanto se compromete a Gerrit.

Es debido a complicaciones como esta que la mayoría de las personas recomiendan encarecidamente trabajar en cada cambio distinto en una rama separada y luego concentrarse en una única confirmación antes de enviar a Gerrit, en lugar de tener que lidiar con este tipo de situaciones donde tiene cambios dependientes que se revisan al mismo tiempo.

Answer 2

Creo que su problema está relacionado con el hecho de que la enmienda al primer compromiso tiene ahora el segundo compromiso como dependencia. Esto es lo que personalmente haría, pero puede haber una mejor manera. Lo veo como si quisieras volver a establecer la base de tus compromisos y estás lidiando con los últimos 3. Entonces ejecuta 'git rebase -i HEAD ~ 3'. Esto le permite volver a establecer las últimas 3 confirmaciones cambiando el orden o combinándolos entre sí.Debe tener en cuenta que enumera los commits en el primer orden más antiguo. He aquí un ejemplo:

git log es el siguiente:

cometer Info: ......

mensaje: foo2

cometer Info: ......

mensaje: Bar1

cometer Info: ......

mensaje: foo1

Después de ejecutar el comando anterior un editor debería elevarse con lo siguiente:

foo1 selección.

pick bar1.

pick foo2.

(Esto es suponiendo que su segundo cambio de foo no cambió ninguno de los archivos que bar1 cambió, ya que esto podría no funcionar y si lo hizo debería haber enmendado la confirmación de todos modos). Luego cambie la lista a esto:

recoger foo1

corrección foo2

selección Bar1

Después de que va a tener foo1 y foo2 aplastados en uno cometió y Bar1 será el compromiso a continuación. Luego ejecutaba 'git reset --soft HEAD ~ 1' reiniciando el último commit, seguido de un 'git commit --amend' que le permite cambiar el mensaje de confirmación para la primera revisión y asegúrese de incluir el id de cambio . Luego prueba tu empuje. Después de eso, debe tener una nueva configuración de parche, y todos los archivos del segundo cambio se modificarán y seguirán en su directorio de trabajo.

Answer 3

llamada

commit --ammend 

lugar para su segundo cambio

Answer 4

he intentado con estos intentos

1. no git rebase -i maestro
   no funcionó
2. luego última lo que hice, hice una copia de seguridad de los archivos. Eliminado todo el proyecto luego lo cloné de nuevo. Pegue los archivos en la carpeta requerida desde la copia de seguridad y luego vuelva a enviarlos de nuevo y luego presione. Funcionó .

Answer 5

simplemente git commit --amend continuación opinión git