Como manter mudanças não confirmadas em um repositório mercurial local, enquanto ainda faz push / pull?
Pergunta
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.
Solução
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.
Outras dicas
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.