Historia lineal mercurial utilizando hg rebase con cambios sin compromiso

Supongamos que tengo varias confirmaciones en el repository local y algunos cambios sin compromiso en el directory de trabajo. Después de hg pull , hg update , obtengo un par de nuevos sets de cambios del repository central que crean una nueva cabeza en el repository local.

Ahora supongamos que no quiero fusionar esas dos cabezas y empujar, en cuyo caso recibiré el post de que tengo cambios sin compromiso en el directory de trabajo, cuando trato de fusionarme.

Además, supongamos que no quiero usar hg shelve para archivar cambios sin compromiso y fusionar sin problemas, pero me gustaría crear un historial lineal usando hg rebase , así que coloco mis confirmaciones sobre commits extraídos. Cuando lo hago de nuevo, efectivamente hago una fusión, como se presenta aquí , bajo el capítulo hg rebase .

Ahora mi pregunta es, ¿ hg rebase el mismo post de error: "no se puede fusionar, hay cambios sin compromiso", ya que hg rebase fusiona implícitamente, o no?

En caso afirmativo, entonces tendré que usar hg shelve en ambos casos: fusión explícita de dos cabezas y combinación implícita al rebasar, ¿no?

Gracias por adelantado,
Aclamaciones

Supongamos que tengo varias confirmaciones en el repository local y algunos cambios sin compromiso en el directory de trabajo. Después de hg pull, hg update, obtengo un par de nuevos sets de cambios del repository central que crean una nueva cabeza en el repository local.

Si tiene cambios no confirmados en el directory de trabajo, y hg pull le da un nuevo encabezado de la stream ascendente, hg update le dirá:

 abort: crosses branches (merge branches or use --clean to discard changes) 

Si intenta fusionarse, recibirá un post sobre la imposibilidad de fusionarse con cambios no confirmados.

Todo esto es por una buena razón: si los cambios no se confirman, están sujetos a perderse para siempre cuando la maquinaria de fusión entra en acción. Debes confirmar o dejar de lado tus cambios no confirmados antes de tratar de fusionar o volver a establecer la base en el código de subida.

También podría considerar usar MQ para ayudarlo con esto; MQ y rebase están diseñados para funcionar bien juntos, por lo que si tus cambios locales no terminados son manejados por MQ, todo lo que tienes que hacer es hg qrefresh; hg pull --rebase hg qrefresh; hg pull --rebase .

La respuesta simple es sí. hg rebase no le permitirá realizar una rebase cuando tenga ediciones no confirmadas. Hay algunas soluciones, ninguna de las cuales es perfecta:

  • Comience su excelente trabajo, haga la rebase, luego hg export tip > foo.patch , hg strip tip , y hg import --no-commit foo.patch .

  • Use hg shelve . No puedo comentar sobre esto en detalle ya que no lo he probado.

  • Cree una nueva twig con nombre con hg branch <branch-name> y comprometa su trabajo sobresaliente en la twig indicada. A continuación, puede usar hg rebase --keepbranches --base <branch-name> --dest default para volver a establecer la base de su twig de trabajo además de los nuevos cambios. Personalmente, encuentro que trabajar con twigs con nombre (que nunca escapan de mi clon hacia arriba) es una forma muy agradable de gestionar este tipo de flujo de trabajo, ya que hace que sea más fácil avanzar y retroceder entre mis proyectos actuales y anteriores, y no hay penalidad por cometer en una sucursal.