¿Cómo puedo enviar un parche sin modificar a gerrit y evitar crear una nueva versión?

Estoy trabajando en un pequeño equipo usando Git / Gerrit como control de código fuente / revisión de código.
Cuando los desarrolladores del equipo quieren enviar su trabajo, se comprometen / presionan a gerrit y comienzan a trabajar en una nueva function.
Además, se alienta a los desarrolladores a impulsar su trabajo siempre que pueden y, por lo general, trabajan por encima de los cambios ya presentados (a través de la selección de los cambios relevantes) que se encuentran actualmente en revisión.

El problema es que cuando los desarrolladores intentan impulsar los cambios, también empujan el historial del cambio. Como efecto secundario, estos cambios obtienen nuevas versiones sin diferencias con respecto a versiones anteriores del mismo cambio. Además, al desarrollador ahora se le debe otorgar un permiso de 'falsificación' (suponiendo que algunos de los cambios seleccionados no fueran suyos)

Ejemplo: Supongamos que el historial de una de las twigs de Adam se ve así (el cambio más alto es el más reciente):

Cambio 3 (Autor: Adam, actualmente trabajando)
cambio 2 (Ahthor: Charlie)
cambio 1 (Autor: Bath)
Dominar

Ahora, los cambios 1,2 se seleccionaron con guinda de gerrit y no cambiaron.
Cuando Adam empuja su parche, debe ser capaz de forzar committer en los cambios 1,2 y get versiones más nuevas (sin ninguna diferencia con el push anterior)

¿Puede alguien aconsejar cómo evitar este comportamiento? ¿Estamos haciendo algo mal?

¡Gracias!

Gerrit está creando nuevas versiones de estos parches porque hubo cambios, cuando los desarrolladores escogieron los cambios que están pendientes de revisión, que modifican la confirmación de git. El compromiso ahora tiene un padre diferente y un SHA1 diferente.

Hay 2 forms de evitar esto:

  1. Tómese el time para revisar / verificar / fusionar adecuadamente los cambios que aún están bajo revisión antes de hacer mucho más trabajo encima de ellos
  2. En lugar de seleccionar cuidadosamente los cambios a nivel local, use el pago y envío. Esto mantendrá el patchset existente tal como está, por lo que cualquier commit en la parte superior se cargará bien sin modificar el patchset existente. Sin embargo, esto moverá su lugar en el repository al lugar donde estaba el patchset cuando se creó; no tendrá ningún commit que se haya fusionado desde que se cargó el patchset.

En dayjob, usamos una combinación de estos 2 enfoques dependiendo de la situación. ¡Buena suerte!

Tuvimos un problema similar en nuestra empresa. Gerrit viene con una secuencia de commands que debe agregar a su repository local (funciona en Windows, Mac y Linux). Se ejecuta automáticamente cuando se realiza una confirmación en su repository local y genera una identificación de confirmación (la agrega al final del post de confirmación).

Si en un momento posterior cambia SHA1 de la confirmación (por ejemplo, para modificarla), Gerrit verá que es la misma confirmación y no creará un nuevo punto de input, solo actualizará los files si la confirmación aún se está revisando.

Para copyr la secuencia de commands vaya a su repository y haga lo siguiente:

scp -p -P 29418 username@path.gerrit.server.com:hooks/commit-msg .git/hooks/