Hg: Como fazer um rebase como o rebit do git

No Git, eu posso fazer isso:

1. Comece a trabalhar no novo recurso:
$ git co -b newfeature-123 # (uma ramificação local de desenvolvimento de recursos)
faça algumas confirmações (M, N, O)

mestre A --- B --- C
                \
novidade-123 M --- N --- O

2. Puxe novas alterações do mestre upstream:
$ git pull
(mestre atualizado com ff-commits)

mestre A --- B --- C --- D --- E --- F
                \
novidade-123 M --- N --- O

3. Rebase off master para que meu novo recurso 
pode ser desenvolvido com relação às alterações upstream mais recentes:
(from newfeature-123)
$ git rebase master

mestre A --- B --- C --- D --- E --- F
                            \
novidade-123 M --- N --- O

Quero saber como fazer a mesma coisa no Mercurial, e procurei na Web por uma resposta, mas o melhor que pude encontrar foi: git rebase - pode hg fazer isso

Esse link fornece 2 exemplos:
1. Admito que isso: (substituindo as revisões do exemplo por aquelas do meu próprio exemplo)

hg up -CF  
hg branch -f newfeature-123  
hg transplant -a -b newfeature-123 

não é tão ruim, exceto que ele deixa para trás o MNO pré-rebase como um cabeçote imerso e cria três novos commits M ', N', O 'que os representam ramificando a linha principal atualizada.

Basicamente, o problema é que eu acabo com isso:

mestre A --- B --- C --- D --- E --- F
                \ \
novidade-123 \ M '--- N' --- O '
                  \
novidade-123 M --- N --- O

isso não é bom porque deixa para trás compromissos locais indesejados que devem ser descartados.

2. A outra opção do mesmo link é

hg qimport -r M: O
hg qpop -a
hg up F
hg branch newfeature-123
hg qpush -a
hg qdel -r qbase: qtip

e isso resulta no gráfico desejado:

mestre A --- B --- C --- D --- E --- F
                            \
novidade-123 M --- N --- O

mas esses comandos (todos os 6!) parecem muito mais complicados do que

$ git rebase master

Quero saber se este é o único equivalente em Hg ou se existe alguma outra maneira disponível que seja simples como o Git.

O VonC tem a resposta que você procura , a extensão Rebase. No entanto, vale a pena gastar um ou dois segundos pensando sobre por que nem mq nem rebase são ativados por padrão em mercurial: porque mercurial é tudo sobre conjuntos de alterações indeléveis. Quando trabalho da maneira que você está descrevendo, quase diariamente, eis o padrão que tomo:

1. Start working on a new feature:
$ hg clone mainline-repo newfeature-123
do a few commits (M, N, O)

master A---B---C
                \
newfeature-123   M---N---O

2. Pull new changes from upstream mainline:
$ hg pull

master A---B---C---D---E---F
                \
newfeature-123   M---N---O

3. merge master into my clone so that my new feature 
can be developed against the latest upstream changes:
(from newfeature-123)
$ hg merge F

master A---B---C---D---E---F
                \           \
newfeature-123   M---N---O---P

e isso é realmente tudo o que é necessário. Acabo com um clone newfeature-123 que posso facilmente retornar à linha principal quando estou feliz com isso. Mais importante, porém, nunca mudei a história . Alguém pode olhar para meus csets e ver com o que eles foram originalmente codificados e como eu reagi às alterações na linha principal ao longo do meu trabalho. Nem todo mundo pensa que isso tem valor, mas acredito firmemente que é o trabalho do controle de origem mostrar-nos não o que desejávamos que tivesse acontecido, mas o que realmente aconteceu - todo beco sem saída e todo refatorador devem deixar um rastro indelével e refazê-lo e outras técnicas de edição de história escondem isso.

Agora vá buscar a resposta do VonC enquanto guardo minha caixa de sabão. :)

Você pode estar procurando a extensão Rebase . (implementado como parte do SummerOfCode 2008 )

Nesses casos, pode ser útil "desanexar" as alterações locais, sincronizar o repositório com o mainstream e, em seguida, anexar as alterações privadas sobre as novas alterações remotas. Essa operação é chamada rebase.

Obtendo de :

para:

Como comentado abaixo por steprobe :

No caso em que você não está realizando as alterações e possui os dois ramos no seu repositório, você pode fazer ( usandokeepbranches ):

hg up newfeature-123 
hg rebase -d master --keepbranches

( --keepbranches: Herda o nome da ramificação original.)

Mojca menciona:

Eu gosto de usar hg rebase --source {L1's-sha} --dest {R2's-sha}, mas não sabia que poderia adicionar --keepbranchesno final.

Como ilustrado abaixo por Jonathan Blackburn :

 hg rebase -d default --keepbranches

Supondo que você tenha uma instalação moderna de Hg, você pode simplesmente adicionar:

[extensions]
rebase = 

para ~ / .hgrc.

Então você pode usar os comandos hg rebase, hg pull --rebaseou hg help rebase.

Não acho que as respostas acima atinjam o objetivo do OP, que era manter seu ramo de tarefas, apenas rebatizado em um ponto posterior no ramo pai.

Digamos que eu comece com este gráfico (gerado usando a extensão graphlog. Amor sério por graphlog).

@  9a4c0eb66429 Feature 3 commit 2 tip feature3
|
| o  af630ccb4a80 default againagainagain  
| |
o |  98bdde5d2185 Feature 3 branch commit 1  feature3
|/
o  e9f850ac41da foo   

Se eu estiver no ramo feature3 e quiser refazê-lo novamente do commit novamente, entendo que eu executaria hg rebase -d default. Isso tem o seguinte resultado:

@  89dada24591e Feature 3 commit 2 tip 
|
o  77dcce88786d Feature 3 branch commit 1  
|
o  af630ccb4a80 default againagainagain  
|
o  e9f850ac41da foo  

Missão cumprida? Acho que não. O problema é que, quando as confirmações na ramificação feature3 foram refazidas novamente, a ramificação feature3 foi excluída . Meus commits foram movidos para a ramificação padrão, que era o que eu estava tentando evitar em primeiro lugar.

No Git, o resultado seria assim:

@  9a4c0eb66429 Feature 3 commit 2 tip
|
o  98bdde5d2185 Feature 3 branch commit 1 **feature3**
|
o  af630ccb4a80 default againagainagain
|
o  e9f850ac41da foo

Observe que a ramificação feature3 ainda existe, as duas confirmações ainda estão na ramificação feature3 e não são visíveis no padrão. Sem preservar a ramificação da tarefa, não vejo como isso é funcionalmente diferente de uma mesclagem.

ATUALIZAÇÃO : Descobri a --keepbranchesbandeira suportada pelo hg rebase e fico feliz em informar que tudo está ok. Usando hg rebase -d default --keepbranches, replico exatamente o comportamento do Git que eu desejava. Alguns apelidos depois, e estou me rebatendo como ninguém.

Como algumas pessoas concordaram em dizer que acham que é bom manter todas as iterações de tudo, vou apontar que, para projetos maiores de código aberto, aceitar mudanças cheias de mesclagens e a iteração de desenvolvimento resultaria em um histórico de revisões da linha principal confuso. o histórico de revisões menos útil para ver como a versão atual chegou lá.

Isso funciona bem quando as alterações enviadas são revisadas por pessoas que não as escreveram, antes de serem aceitas; portanto, as alterações que entram na linha principal geralmente são depuradas e funcionando. Então, quando você retorna à origem de uma linha, vê todas as mudanças que a acompanham, e não em algum momento no meio do desenvolvimento da mudança da qual faz parte.

A página de contribuidores do x265 explica como reenviar um conjunto de alterações nas quais você está trabalhando, para prepará-los para o envio ao projeto x265. (Incluindo o uso do TortoiseHG para confirmar algumas, mas nem todas, as alterações em um arquivo individual, como o estágio do diff do estágio / unstage do git gui para commit).

O processo é atualizar o hg para a ponta do upstream e, em seguida, descomprimir todas as suas alterações no diretório de trabalho. Arquive qualquer que não faça parte do que você deseja enviar e divida o restante em quantas confirmações separadas forem apropriadas, com boas mensagens de confirmação.

Eu acho que você copia / cola e edita as mensagens de confirmação de iterações anteriores de um conjunto de patches que você está revisando. Ou talvez você possa enxertar seus commits antigos (escolher cereja no idioma git) e alterá-los um por um, para obter suas mensagens de commit antigas como ponto de partida para a edição.