¿Se considera `qrefresh` dañino?

Question

El comando qrefresh en la extensión MQ no tiene sentido para mí. Explicaré mi suposición:

1. Si no sabe en qué revisión se debe aplicar un parche determinado, tiene muy poco valor. Simplemente no se puede saber teóricamente qué significan los rechazados. E incluso si no hay rechazos en una revisión determinada, no está seguro de que la revisión completa compilaría.
2. Una vez que qrefresh un cierto parche en la cola de parches, en realidad está perdiendo el padre del siguiente parche en la cola. Para que sin su intervención este próximo parche sea/pueda ser inútil.
3. Para arreglar el próximo parche, es mejor fusionarlo en lugar de editar manualmente los archivos .rej. No solo por las mejores herramientas, si tiene el parche original qrefresh 'ed, tiene más información, el qrefresh le hizo perder la información que realmente necesita para que el cambio realizado en el parche sea significativo.

Por lo tanto, no entiendo por qué uno querría usar este comando.

Una mejor alternativa es aplicar todos los parches, luego hg update al padre del parche que desea cambiar, entonces, hg revert el directorio de trabajo del parche que desea cambiar. Cambie este parche, comprométalo con una nueva revisión y luego vuelva a establecer la base de todos los demás parches en esta nueva revisión.

Simplemente no entiendo cuando qrefresh es relevante cuando no está editando un solo parche solamente. Parece que el enfoque de git (aplicar el parche a una sucursal local) tiene mucho más sentido que una cola de parches.

¿Estoy en lo correcto, y será mejor que use rebase? ¿Hay algo que eché de menos?

emigraron de kiln.se.com debido a la falta de respuesta y de visión baja tasa

Answer 1

EDITAR: después de escribir la respuesta a continuación, me topé con la chapter about patches de Mercurial La guía definitiva . Dice más o menos lo mismo, pero es mucho más que mi respuesta detallada. También sugieren una forma (un poco intrincada para mi gusto , pero de todos modos) para utilizar la combinación 3-way con parches, ya que el OP estaba buscando para.

¿Quizás vea mq solo como una herramienta de importación de parches? Ese no es mi uso principal, y para mí qrefresh es muy útil. El caso típico de uso para mí es cuando estoy trabajando en la parte superior del repositorio publicado.

Normalmente trabajo con una serie de parches que estoy escribiendo al mismo tiempo. Comienzo creando un nuevo parche vacío. Cuando creo que se ha terminado alguna característica (parte de una), I qrefresh el parche superior para incluir todos los cambios realizados desde el momento de creación del parche (o el último qrefresh). Luego creo un nuevo parche vacío y sigo escribiendo el código que pertenece al siguiente parche.

Si más tarde, cuando trabajo en otro parche, veo algún cambio que debe hacerse dentro de un parche anterior (porque lógicamente pertenece), no realizo el cambio en el parche superior ni creo un parche nuevo . Primero I qrefresh el parche actual, luego qpop al parche anterior al que pertenecen los cambios, luego realizo mis cambios. Cuando se hace I qrefresh de nuevo el parche anterior, luego qpush volver a donde estaba trabajando, y así sucesivamente.

Cuando trabajas de esta manera, las fusiones suelen ser muy sencillas y casi no tengo rechazos qpop ing y qpush alrededor.

Cuando creo que mi serie completa de parches está lista para publicarse, I qfinish toda la serie, y empiezo de nuevo con una nueva pila de parches vacía.

Es posible hacer el mismo tipo de cosas con rebase, pero entonces necesitaría una función como git interactive rebase.

El objetivo de trabajar con parches es que los parches aún no se han comprometido, por lo que pueden cambiarse fácilmente, y para eso necesita qrefresh. Bueno, podría lograr el mismo resultado creando nuevos parches y qfold ing ellos, pero realmente no tendría sentido hacerlo, solo dos comandos en lugar de uno.

Ahora, cuando los parches son contribuciones externas, como un mantenimiento principal para las contribuciones de mi proyecto se incluyen desde parches proporcionados por los contribuyentes y nunca llegan directamente al repositorio. Primero entran en mi pila de parches principal. Si realizan cambios en las mismas partes del programa en el que estoy trabajando, es probable que causen rechazos (y si es así, basicamente no lo inserto, es probable que cause estragos). Si se aplican a alguna otra parte del programa que no se cambia actualmente, básicamente se fusionan sin ningún problema y se puede importar en cualquier punto de la pila de parches, sin obligación de insertarlos en una revisión específica. Pero siempre leo los cambios, y muy a menudo cambio ligeramente el código contribuido. Entonces otra vez uso qrefresh para actualizar el parche externo a lo que creo que debería ser.

Answer 2

Usted debe escoger la respuesta de Kriss, s/él lo explica todo muy bien, pero aquí hay un artículo sobre el software que inspiró la función de gestión de parches en tanto voluble y GIT, edredón:

http://www.suse.de/~agruen/quilt.pdf