Pergunta

Eu uso Tortoise SVN usuallly, mas eu tenho procurado em Mercurial uma vez que é um sistema de controle de revisão distribuído.

O que eu estou procurando, em ambos os sistemas, é uma ferramenta que deixe-me escolher apenas partes de um arquivo e cometê-los. Se eu quiser fazer isso agora, eu tenho que copiar para uma versão temporária do arquivo e manter apenas as mudanças que querem cometer na versão atual e, em seguida, copiar a versão temp para a versão atual novamente após cometer. É apenas como um aborrecimento e o programa deve ser capaz de fazer isso por mim.

Eu ouvi Git suporta isto, por favor deixe-me saber se isso é correto.

Foi útil?

Solução

Mercurial pode fazer isso com o extensão recorde .

Ele vai pedir-lhe para cada arquivo e cada pedaço diff. Por exemplo:

% hg record
diff --git a/prelim.tex b/prelim.tex
2 hunks, 4 lines changed
examine changes to 'prelim.tex'? [Ynsfdaq?]  
@@ -12,7 +12,7 @@
 \setmonofont[Scale=0.88]{Consolas}
 % missing from xunicode.sty
 \DeclareUTFcomposite[\UTFencname]{x00ED}{\'}{\i}
-\else
+\else foo
 \usepackage[pdftex]{graphicx}
 \fi

record this change to 'prelim.tex'? [Ynsfdaq?]  
@@ -1281,3 +1281,5 @@
 %% Local variables:
 %% mode: latex
 %% End:
+
+foo
\ No newline at end of file
record this change to 'prelim.tex'? [Ynsfdaq?]  n
Waiting for Emacs...

Após a confirmação, o diff restante será deixado para trás:

% hg di
diff --git a/prelim.tex b/prelim.tex
--- a/prelim.tex
+++ b/prelim.tex
@@ -1281,3 +1281,5 @@
 %% Local variables:
 %% mode: latex
 %% End:
+
+foo
\ No newline at end of file

Como alternativa, você pode achar que é mais fácil de usar MQ (Mercurial filas) para separar as mudanças individuais em seu repositório em patches. Existe uma variante MQ de registro (qrecord), também.

Update: Além disso, tente a extensão crecord , que fornece uma interface para maldições pedaço selecção / linha.

Captura de tela crecord

Outras dicas

Sim, git permite que você faça isso. O comando git add tem uma opção -p (ou --patch) que lhe permite rever as suas alterações Pão-por-pedaço, selecionar qual a etapa (você também pode refinar os blocos ou, editar os patches no lugar). Você também pode usar o modo interativo para git-add (git add -i) e use a opção "p".

Aqui está um screencast em acrescentando interativo que demonstra também o recurso de correção de git add.

Confira TortoiseHG, que fará a seleção pedaço e deixá-lo cometer diferentes alterações a um arquivo como a diferentes commits.

Ele vai mesmo deixar você confirmar todas as alterações a alguns arquivos junto com mudanças parciais para outros arquivos em um commit.

http://tortoisehg.bitbucket.io/

Eu perguntei a um pergunta semelhante apenas um pouco atrás, e a resposta resultante de utilizar o extensão hgshelve foi exatamente o que eu estava procurando.

Antes de fazer um commit, você pode colocar as mudanças de diferentes arquivos (ou pedaços de mudanças dentro de um arquivo) na "prateleira" e, em seguida, cometer as coisas que você quer. Então você pode unshelve as alterações que não cometeram e continuar a trabalhar.

Eu tenho usado nos últimos dias e gosto muito. Muito fácil de visualizar e usar.

Mercurial agora oferece uma --interactive opção (ou -i) para o comando commit, que permite essa funcionalidade para a direita fora da caixa.

Isso funciona directamente a partir da linha de comando por isso é perfeito se você é um entusiasta de linha de comando!

Running

> hg commit -i

inicia uma sessão interativa que permite o exame, edição e gravação de mudanças individuais para criar uma confirmação.

Este se comporta de forma muito semelhante às opções --patch e --interactive para os comandos git add e git commit.

Eu recomendaria não funciona assim.

Se tiver de conjuntos de mudanças, defina um que está pronto para o check-in e um conjunto B, que ainda não está pronto, como você pode ter certeza que apenas o check-in conjunto A não vai quebrar sua compilação / testes? Você pode perder algumas linhas, esquecer-se sobre linhas em um arquivo diferente, ou não perceber uma dependência que A tem a B quebrar a construir para os outros.

As suas submissões devem ser discretas mudanças atômicas que não quebrar a construir para você ou outros em você equipe. Se você está cometendo parcialmente um arquivo que você está aumentando as chances que você vai quebrar a construir para os outros sem saber sobre ele até que você tenha algum colega de trabalho infeliz batendo em sua porta.

A grande questão é, por que você sente a necessidade de trabalhar desta maneira?

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top