Como manter mudanças não confirmadas em um repositório mercurial local, enquanto ainda faz push / pull?

Question

Se estou trabalhando em alguns arquivos que não quero enviar, apenas os salvo. Eu tenho outros arquivos que quero enviar por push para o servidor, no entanto, se outra pessoa fez alterações no repositório e eu os puxo para baixo, ele me pede para mesclar ou realocar .. mas qualquer uma dessas opções me causará para perder minhas alterações locais que não cometi .

O que outras pessoas estão fazendo para contornar isso? Acho difícil entender a documentação da extensão da estante.

Observação: estou usando o Mercurial Eclipse para enviar e receber arquivos de / para o servidor.

Qualquer explicação sobre isso seria muito apreciada! Obrigado!

---

Exemplo:

Estou trabalhando no meu site no Mercurial Eclipse. Tenho uma nova pasta e novos arquivos que não quero enviar para o servidor ainda. Também modifiquei alguns arquivos existentes e não quero fazer essas alterações ativas ainda.

Então algo no meu site quebra e eu preciso consertar, ele não me deixa consertar sem rebasing ou mesclar com a dica mais recente do repo e isso me fará perder todas as minhas alterações não confirmadas.

O que devo fazer com minha nova pasta e arquivos que editei se não quiser perdê-los? A reclonagem parece entediante. Copiar os arquivos para uma nova pasta também parece tedioso. Tenho certeza de que o Shelving ou o MQ farão o que eu quero, só não sei como fazer isso ainda.

Answer 1

Tenho certeza de que alguém o ajudará a encontrar uma solução ruim, mas o melhor caminho é mudar seus objetivos - basta se comprometer.O código que não foi confirmado não foi escrito.Se você positivamente não pode suportar commits frequentes em sua história, use Mercurial Queues com um repositório de filas e faça o commit.Você pode então colocar os changesets, push / pull / merge e empurrá-los de volta, e todo o seu trabalho valioso será enviado para a fila de patch.

Answer 2

Com referência ao seu exemplo de situação, aqui está o que eu faria (seguindo a estratégia de Ry4an de apenas comprometer as coisas nas quais você está trabalhando atualmente, mas não deseja publicar já):

Suponha que você comece a trabalhar em um repositório como este:

$ hg status -A
C f1
C f2
$ hg glog
@  changeset:   1:7f3c6c86a92f
|  tag:         tip
|  summary:     add f2
|
o  changeset:   0:03ca1e6d5b86
   summary:     initial

Ou seja, existem 2 arquivos e 2 commits / changesets. Você faz algum trabalho, digamos, adiciona um novo recurso, e então sua cópia de trabalho pode ficar assim:

$ hg status
M f2
? f3
? f4

Existem 2 arquivos novos e 1 modificado. Agora você precisa consertar um bug para o qual também precisa de novas alterações em um repositório remoto. Faça um instantâneo de seu trabalho atual ao submetê-lo e extrair as alterações remotas (em que ordem você faz isso não importa, uma solicitação por padrão não altera o estado de sua cópia de trabalho):

$ hg commit -A -m "snapshot feature work"
$ hg pull

Isso pode resultar em um histórico como este:

o  changeset:   3:2284ba62de07            <-- just pulled in
|  tag:         tip
|  parent:      1:7f3c6c86a92f
|  summary:     edit f1
|
| @  changeset:   2:4a19d371a04f          <-- your interrupted work
|/   summary:     snapshot feature work
|
o  changeset:   1:7f3c6c86a92f
|  summary:     add f2
|
o  changeset:   0:03ca1e6d5b86
   summary:     initial

Agora você pode atualizar para / verificar a revisão 3 e começar a corrigir os bugs:

$ hg update 3
.. fix the bug ..
$ hg commit -m "fix a bug"
$ hg glog --limit 3
@  changeset:   4:5d3d947fb4af
|  tag:         tip
|  summary:     fix a bug
|
o  changeset:   3:2284ba62de07
|  parent:      1:7f3c6c86a92f
|  summary:     edit f1
|
| o  changeset:   2:4a19d371a04f
|/   summary:     snapshot feature work
:

Parece bom, vamos forçar sua correção, ou seja, torná-lo ao vivo, sem publicar seu trabalho intermediário:

$ hg push -r 4

Isso empurra todas as mudanças que levam à revisão 4, sua correção de bug, mas nenhum outro branch em seu repositório local. Você também pode usar -r ., que se refere à revisão pai de sua cópia de trabalho, ou seja, a revisão que você acabou de enviar.

Finalmente, você pode voltar ao trabalho de feição e continuar seu trabalho:

$ hg update 2
.. work, commit, work, commit ..
.. finally merge with the other branch, e.g. revision 4

Essas etapas estão na linha de comando, mas acho que não é difícil adaptar o conceito geral aos cliques correspondentes no plug-in Eclipse Mercurial.

Algumas notas extras:

• Você pode querer marcar seu commit de instantâneo, então você não precisa trabalhar com IDs de revisão ou números.
• Se você deseja publicar seu trabalho de feição em um único commit posteriormente, use a extensão recolher quando terminar.