hg queues mq (anidadas | sub | secundarias)

Sé que esta no es una function de hg, pero tal vez alguien sepa cómo get algo similar. Espero que mi descripción tenga sentido:

Me resulta útil para mantener mi línea principal (es decir, la twig pnetworkingeterminada) se compromete en una queue de parches durante unas semanas para que puedan "resolver". Sin embargo, también me gustaría poder crear twigs temáticas a través de nuevas queues. Estas dos ideas son mutuamente excluyentes, ya que no puede crear nuevas queues a partir de un parche aplicado. Parece que la única forma de hacerlo es finalizar mis parches de la línea principal, iniciar las queues de las twigs de la confirmación de qparent y manejar los ajustes mediante la import de parches finalizados a mq. ¿Alguna otra idea? ¿Es mejor en este tipo de flujo de trabajo?

Voy a advertir esta respuesta con "No lo he probado y no tengo idea de si funcionará o si es lo que quieres".

Cuando crea un MQ para su repository, lo crea como un nuevo repository Mercurial dentro del actual, por lo que su estructura interna es algo como esto:

.hg\ cache\ patches\ .hg\ .hgignore patch1 patch2 series status store\ hgrc ... 

Puedes realizar operaciones directamente en el repository de parches (de hecho, si eres como yo, tendrás algún tipo de script configurado para trabajar fácilmente en ese repository; para mí tengo el command mq ).

Como MQ es un repository en sí mismo, se puede comprometer, tirar, empujar, etc. En teoría, esto podría include ramificaciones.

Un posible flujo de trabajo sería que, cada vez que creas que estás contento con un parche, lo comprometes con el repository de parches:

 hg qnew Patch3 -m "something" ... hg qref mq commit -m "happy with patch3" 

Tenga en count que esto no está comprometiendo el parche en su repository principal, simplemente almacena el historial del parche. Si en algún momento decidiste que querías crear una sucursal, podrías hacerlo con:

 mq branch SomeBranch hg qnew Patch4 -m "something else" ... hg qref mq commit -m "Committing to the new patch branch" mq update default 

El parche Patch4 ahora está ramificado, y no aparece en su serie de parches, incluso en la list no aplicada.

Es una solución posible que podría funcionar, pero tendría que ser probada exhaustivamente en un repository de testings, y si no tiene cuidado, también podría ir terriblemente mal.

mq tiene la funcionalidad de guard que podría darle la flexibilidad que necesita, tal como se describe en el libro hg . Suponiendo que tienes tres parches:

  • patch-a : tu parche principal que estás dejando "resolver"
  • patch-b : un nuevo parche con trabajo incompleto en feature1
  • patch-c : un nuevo parche que comienza feature2

Solo necesita asignar un guardia donde sea necesario:

 hg qpop -a hg qguard patch-b +feature1 hg qguard patch-c +feature2 hg qselect feature2 hg qpush -a 

En este punto, mq empujará todos los patch-a sin protección ( patch-a ) y con protección positiva ( patch-c ), salteando el patch-b ya que tiene un protector que no está seleccionado actualmente. Los parches sin protección siempre se aplican. También hay protecciones negativas (p. Ej. hg qguard -- -feature1 ) que evitan la aplicación del parche cuando se selecciona la protección.

Para cambiar a feature1:

 hg qpop -a hg qselect feature1 hg qpush -a 

Tenga en count que si está haciendo tanto trabajo en la queue de parches, debe comprometer la queue con bastante frecuencia para rastrear sus cambios en la queue (usando hg com --mq ).

Es posible que desee consultar https://www.mercurial-scm.org/wiki/ChangesetEvolution .

Es bastante posible que este flujo de trabajo sea un poco más fácil en git.