Flujo de trabajo con Mercurial: eliminar compromisos antiguos al volver a establecer una base de parche

Me gustaría entender cuál es la mejor manera de realizar el flujo de trabajo que voy a presentar con Mercurial. Sé cómo lo haría en Git, con lo cual estoy mucho más seguro, pero no pude encontrar una manera satisfactoria con Mercurial.

El flujo de trabajo es el siguiente: quiero rastrear una twig ascendente, donde el trabajo de desarrollo es realizado por otra persona, y mantener una twig de parche razonablemente pequeña encima de ella. Lo que haría con Git es lo siguiente: cada vez que quiero include un nuevo compromiso ascendente, rebase mi twig de parche sobre la twig ascendente (o la confirmación pertinente, por cierto), tal vez modifique alguna confirmación y presione forzosamente la twig de parche para un repository que se comparte con mis queueboradores (soy consciente de los problemas con los empujes no rápidos y también lo son mis queueboradores, sabemos cómo evitar problemas).

Me gustaría hacer lo mismo con Mercurial. El principal problema es que cada vez que presiono una nueva cabecera, la anterior no se elimina como ocurre con Git (vale, los commits no se eliminan realmente, pero prácticamente desaparecen, ya que ya no son antepasados ​​de ninguna twig ; finalmente serán eliminados por git gc y eso está bien para mí). Así que mi repository sigue contaminado con muchos compromisos antiguos que ya no quiero. No pude encontrar ninguna forma de eliminarlos (excepto tal vez borrarlos uno por uno, pero esa no es realmente una solución).

¿Hay alguna forma mejor de hacer esto con Mercurial?

En otras palabras, lo que me gustaría hacer es eliminar automáticamente todas las confirmaciones que no son antepasados ​​de alguna confirmación en un set pnetworkingeterminado.

EDITAR : ya que alguien está pidiendo más detalles, trato de ser más preciso. Comienzo con este repository:

 C <upstream> | B | A | 

Luego desarrollo algunos parches en él:

 F <patch> | E | D | C <upstream> | B | A | 

En algún punto upstream agrega algunos commits más:

 F <patch> I <upstream> | | EH | | DG | | C ---------+ | B | A | 

Rebase mi twig de parche en ella, tal vez modifique algo en los parches y llegue aquí:

 F' <patch> | E' | D' | I <upstream> | H | G | C | B | A | 

Luego presiono todo en el repository remoto de Mercurial:

 F' <patch> F | | E' E | | D' D | | I ----------+ <upstream> | H | G | C | B | A | 

Mercurial no elimina automáticamente la D, E, F cabeza, pero me gustaría que desaparezca. Hago este ciclo de pull / rebase / modify / push a menudo y me gustaría borrar viejos comillas sobrantes que ya no son relevantes. ¿Cómo puedo hacer eso?

Gracias.

Conozco el dolor y no tengo una solución automática a mano. Trato de no permitir que se acumule demasiado cruto (comprobado regularmente con hg heads -t ) y uso la hg strip para eliminar los sets de cambios no deseados del repository. La eliminación no se realiza una por una (set de cambios), si elige el set de cambios correcto, generalmente solo hay una tira para cada ciclo de rebase, porque todos los descendientes del set de cambios eliminados también se eliminan: el repository no puede tener huérfanos. Encontrar el set de cambios correcto es un poco tedioso, pero como normalmente solo se trata de un par de parches, no es demasiado difícil usar hg glog .

Si su tarea comercial es

  • Obtenga cambios de RepoOne
  • Combina estos cambios con tu línea principal
  • Publicar resultados de fusión en RepoTwo

tienes al less dos (pensamiento sucio sin testings profundas) forms de hacerlo de manera más Mercurial

Sucursal

  • Mantenga su línea principal en una twig con nombre diferente ANYNAME ! = Pnetworkingeterminado (valor pnetworkingeterminado más utilizado probablemente por la ANYNAME )
  • Tener un upsteam-repo en la sección de paths de .hgrc para poder extraerlo
  • Tire, cuando sea necesario, del upsteam
  • ANYNAME con ANYNAME , resuelve conflictos, si hay alguno
  • Confirme y presione su repo solo ANYNAME branch hg push -b ANYNAME (efecto secundario: los padres de mergeset de upstream también serán presionados)

MQ-way

  • Tener la extensión MQ habilitada en su repository
  • Convierta sus parches locales en el parche de MQ (en la parte superior del código de flujo ascendente) en una twig común
  • Tener un upsteam-repo en la sección de paths de .hgrc para poder extraerlo
  • Tire, cuando sea necesario, de la stream ascendente
  • Combinar parches con aguas arriba
  • Para el intercambio de parches, tiene dos forms
    • si patch-queue se creó como repository ( hg qinit -c ) puede insert este repository además de "base"
    • El uso de la extensión MQCollab en la parte superior de MQ le permitirá intercambiar y sincronizar parches con queueboradores directamente (que también deben tener MQ y MQCollab)