¿No es esto un flujo de trabajo normal?¿Por qué es necesario un distintivo --new-branch?
[default] $ hg branch foo
[foo] $ [... some commits ...]
[foo] $ hg update default
[default] $ hg merge foo
[default] $ hg commit -m "merged foo"
[default] $ hg push
abort: push creates new remote branches: foo!
(use 'hg push --new-branch' to create new remote branches)
¿Cuál es la otra forma ideal de hacer bifurcaciones → fusionar → presionar?
La filosofía mercurial es que no deberías estar presionando cosas que lo hagan más difícil para otros usuarios del repositorio. Pertinente a esta pregunta es que múltiples cabezales hacen que sea más difícil para otros desarrolladores, ya que luego necesitarían fusionar sus cambios. Por lo tanto, por defecto, el servidor rechaza la inserción de nuevas cabezas. La opción -f se usó para permitir empujar cabezas nuevas.
Sin embargo, el caso de empujar una nueva rama con nombre es bastante diferente conceptualmente a empujar una nueva cabeza en la misma rama. Muchos flujos de trabajo (incluido el mío) realizan cada tarea en una rama con nombre diferente. La opción --new-branch le permite empujar hacia arriba una nueva rama, mientras rechaza las nuevas cabezas en las ramas existentes. También es diferente (como has visto) porque es necesario incluso si la nueva rama no crea una nueva cabecera (debido a la fusión).
Mi sensación personal es que las nuevas sucursales deberían permitirse por defecto, pero los desarrolladores de mercurial prefieren lo contrario.
Esto es algo único. Solo use --new-branch la primera vez que presione una (nueva) rama. Es normal.
Cualquier otro impulso puede permanecer como hg push, no --new-branch marca.
¿Qué ocurre si hago una '--close-branch' para eliminar la rama nombrada antes de un push? No debería abortar, ¿no? Se me acaba de ocurrir ahora. –
Eso depende de para qué se utiliza la rama.
Si se usa internamente en su propio clon del repositorio, sería apropiado enviar los cambios a su sucursal siempre que desarrolle su función desacoplada de las demás.
Después de terminado tendrá que invertir algo de trabajo para realizar un seguimiento de los esfuerzos de otras personas que pueden haber hecho cambios en la rama por defecto
A continuación, debe actualizar en sus cambios, resolver los conflictos de comprometer su parte. Cambie a la configuración predeterminada y convierta su función en parte de la rama predeterminada al fusionarse en sus cambios. ¡Ahora puede cerrar su sucursal, comprometerse y presionarlo!
He usado hg durante * dos años *, y no entiendo a qué te refieres. ¿Estás respondiendo la pregunta? –
especulativamente, porque internamente una nueva rama es una nueva cabeza, y hg se resiste a enviar nuevas cabezas con la opción -f (fuerza). –
La diferencia en su comprensión podría ser que en Mercurial (a diferencia de git) aunque haya combinado foo en predeterminado, todavía está enviando algunos conjuntos de cambios cuyo atributo de rama inmutable es 'foo'. En git, el nombre foo nunca escaparía de tu sistema local con esos comandos, pero en Mercurial, si quieres ese comportamiento, utilizas marcadores que no se llaman ramas. –