Nuevo mando a distancia cuando se empuja una nueva rama

Question

He creado una rama named en mercurial, he realizado algunos cambios y ahora quiero volver a enviarla al repositorio central. He hecho una búsqueda, verifiqué que no tengo cambios para fusionar, pero cuando intento hacer el push, obtengo el mensaje push creates new remote head pero no entiendo por qué. Soy el único desarrollador en esta rama y sigue siendo local para mi repositorio.

>hg fetch (pull/update/merge) 
>hg status (shows nothing) 
>hg push --new-branch mybranch 
searching for changes 
new remote heads on branch 'default' 
new remote head c3064f3cf1b7 
abort: push creates new remote head c3064f3cf1b7! 
(did you forget to merge? use push -f to force) 

¿Alguna idea?

Editar: lo siento por cualquier confusión, esto es una rama llamada creado por hg branch mybranch

actualización: usando hg heads produce múltiples cabezas de todos en diferentes ramas. Tengo uno para mi rama, y ​​uno bajo predeterminado:

changeset: 515:97b9a7802751 
branch:  mybranch 
user:  me <me@mymail.com> 
date:  Mon Feb 27 13:21:54 2012 -0800 
files:  CryptoRandom.cs 
description: 
fixing error message for size of max 


changeset: 504:c3064f3cf1b7 
user:  me <me@mymail.com> 
date:  Thu Feb 09 11:41:32 2012 -0800 
files:  CipherKey.cs 
description: 
removing ambiguous characters - CAC-47 

usando hg log -r c3064f3cf1b7 se obtiene la siguiente (esta es la cabeza en forma predeterminada):

changeset: 504:c3064f3cf1b7 
user:  me <me@mymail.com> 
date:  Thu Feb 09 11:41:32 2012 -0800 
files:  CipherKey.cs 
description: 
removing ambiguous characters - CAC-47 

Answer 1

Simplemente resuelto mágicamente esto, pero aún no está claro por qué. Parece ser un problema con default aunque no estoy trabajando en esa rama. Podría llamar al >hg branch y obtener el nombre de la rama esperada.

Tuve un cambio en mi rama local default que no fue empujada, y no quise. Me retracté de ese cambio y luego me comprometí. Luego hice un fetch en la rama predeterminada y lo fusioné con mi rama de características. Luego volví al default Me fusioné con el conjunto de cambios predeterminado que abandoné, creo. En algún momento durante ese proceso obtuve otra cabeza, lo que probablemente causó las fusiones múltiples.

Parece que todo se reduce a las cabeceras existentes en el valor predeterminado, pero todavía no sé por qué (o por qué querríamos) que afecte a una rama con nombre diferente.

Todo esto parece demasiado complicado para lo que espero que suceda (y lo que cada uno puede simplemente dibujar en diagramas ascii)

Editar

Parece que el problema surgió durante la rama inicial tal vez. Parece que he ramificado dos veces y [j] es una sucursal anónima predeterminada.

al tipo de visualizar lo que parece estar sucediendo es mi [j] conjunto de cambios Salí de [k] y es mi primer informe de cambios en MyBranch:

[a] -- [b] -- [c] -- [d] -- [e] (default) 
     \    \ /
      [j]-----------\---  (not sure where this branch came from) 
      \   \ 
      [k] -- [l] -- [m] (mybranch. Still separate from default) 

Answer 2

El confuso es que la bandera --new-branch no tiene ningún efecto al presionar ramas de función (también conocido como anynomous ramas). Una rama en el anonimato se ve así:

... [a] --- [b] --- [c] <- the servers head on default 
       \ 
       [x] --- [y] <- my feature branch on default 

Todos los cambios son en default por lo que ahora tiene dos cabezas en default. Cuando presionas, crearás dos cabezas en el servidor, pero Mercurial cancela antes de eso con la advertencia que ves. Se cancela ya que tener varias cabezas en un servidor es confuso: cuando hg clone su copia de trabajo se actualizará a uno de ellos, casi al azar.

La bandera --new-branch es solo para named branches. Mercurial normalmente abortará si empujas una nueva rama con nombre a un repositorio remoto. Agregar la bandera --new-branch es cómo le dices que siga adelante.

Desafortunadamente, no tenemos una bandera dedicada --create-new-feature-branch. Solo tenemos la bandera --force que le dice a Mercurial que continúe y cree las dos cabezas en el repositorio remoto. La desventaja de --force es que anula todas las verificaciones de seguridad: puede empujar tres o más cabezales nuevos con esa bandera e incluso puede insertar en un repositorio no relacionado. Por lo tanto, debe usar hg outgoing para verificar qué va a presionar.

Escribí anteriormente que las cabezas múltiples en el servidor son confusas ya que un nuevo clon se actualizará a una cabeza aleatoria. Para evitar la confusión, puede asignar los nombres de las ramas de características marcando ellos. Seguirá siendo actualizado a un encabezado aleatorio, pero hg bookmarks le mostrará las ramas de características disponibles y luego podrá actualizarlas a la correcta. Entonces, si está utilizando dicho flujo de trabajo, continúe con hg push -f.