Eu sou um usuário git confuso com a ramificação do mercurial. Como devo rastrear pequenas alterações?

Eu sempre usei o git antes, mas quero contribuir com o python, agora tenho que aprender mercurial e acho isso muito frustrante.

Então, eu fiz alguns pequenos patches e queria rastreá-los como confirmações no meu repositório mercurial local. Aparentemente, existem 4 maneiras de lidar com ramificações no mercurial . 1 e 4 pareciam completamente ridículos para mim, os ramos nomeados parecem pesados, e acho que não devo usá-los para correções rápidas de 1 commit, por isso usei indicadores.

Agora, meu patch é rejeitado e quero remover um dos meus favoritos do meu repositório. OK, no git, eu apenas excluiria minha ramificação forçada e a esqueceria; portanto, excluo meu marcador e agora tenho os seguintes problemas:

• TortoiseHG e hg logainda mostra que commit e defaultbranch tem 2 cabeças. E se eu entendi corretamente, você não pode excluir commits em hg sem plugins adicionais.

• O Mercurial não possui apenas hashes, mas também números de revisão. Como adicionei alguns de meus próprios commits, todos os commits recebidos depois disso têm números de revisão diferentes do repositório central principal.

• Eu o faço hg updatedepois de puxar para mover meu mastermarcador para o commit mais recente automaticamente, mas não consegui encontrar uma maneira de fazer isso no TortoiseHG.

O que estou fazendo errado? Isso é normal e esperado e devo apenas ignorar esses problemas? Ou como devo trabalhar com minhas filiais?

Pessoalmente, para o seu cenário, eu nem me preocuparia em criar uma ramificação, a menos que estivesse trabalhando em várias alterações, cada uma das quais precisaria ser aceita pelos desenvolvedores principais.

Apenas clone o repositório e trabalhe nele e faça uma solicitação de recebimento.

Se eu usar um ramo, prefiro usar ramos nomeados. Eles foram projetados para esse objetivo exato, onde os marcadores não eram. Não vejo por que você consideraria pesado.

Mercurial tem uma página inteira em seu wiki descrevendo diferentes maneiras de " Podar galhos mortos ". A opção "Usando clone" deve atender aos seus requisitos.

Para responder a seus problemas mais específicos ...

O TortoiseHG e o hg log ainda mostram que o commit e o branch padrão possuem 2 cabeças. E se eu entendi corretamente, você não pode excluir commits em hg sem plugins adicionais.

Este é um erro que cometi com o Mercurial quando eu era novo. Não tenha medo desses plugins adicionais. Algumas delas são ferramentas muito poderosas e, muitas vezes, mais tarde são atraídas para o produto principal. É assim que a Mercurial funciona. Se você precisar de uma para executar uma tarefa específica, obtenha-a e use-a.

A revisão da história é considerada uma coisa ruim no mundo Mercurial; portanto, o produto baunilha nem sempre tem tudo o que um usuário do Git pensa que deveria ter, mas há muitos plugins para quem deseja usar o aplicativo, mas tem prioridades diferentes.

O Mercurial não possui apenas hashes, mas também números de revisão. Como adicionei alguns de meus próprios commits, todos os commits recebidos depois disso têm números de revisão diferentes do repositório central principal.

Não se preocupe com os números de revisão. Eles são uma questão de conveniência, não mais. Os códigos de hash são os identificadores importantes que passarão de repo para repo. Os números de revisão são inconsistentes nos repositórios. Confira Hg Init para uma boa explicação.

Os números de revisão são apenas um atalho útil e mais memorável ao trabalhar com um único repositório.

Eu atualizo o hg depois de puxar para mover automaticamente o meu marcador principal para o commit mais recente, mas não consegui encontrar uma maneira de fazer isso no TortoiseHG.

Ao usar o TortoiseHG, use o Workbench em vez de outras ferramentas. Tudo (quase) está lá. A atualização está nos menus de contexto da revisão. Nem sempre é intuitivo, mas há um bom guia no link acima e, à medida que você se acostuma, acaba clicando com um abandono confiante.

Aparentemente, existem 4 maneiras de lidar com ramificações no mercurial. 1 e 4 me pareciam completamente ridículos, os galhos nomeados parecem pesados

No Mercurial, você não cria ramificações. Cada confirmação é efetivamente um ramo, qualquer confirmação pode ter vários pais e vários filhos. Portanto, essas são as quatro maneiras diferentes de organizar as mesmas entidades.

Você pode dar nomes diferentes a eles, não precisa , mas é uma boa ideia. Não há nada pesado sobre as ramificações nomeadas - são apenas alguns metadados extras. Pessoalmente, prefiro ramos nomeados a qualquer outra coisa em qualquer situação.

O TortoiseHG e o hg log ainda mostram que o commit e o branch padrão possuem 2 cabeças.

Qual é exatamente o motivo para usar ramificações nomeadas em vez de despejar tudo default.

E se eu entendi corretamente, você não pode excluir commits em hg sem plugins adicionais.

Você não pode realmente excluir nada do Mercurial e não deveria . Você pode usá- hg striplo, mas não está logado - você basicamente interrompe uma parte do seu repo local. Você não pode empurrar isso e, se você extrair de um repositório que possui o ramo que você retirou localmente, ele volta.

O Mercurial não possui apenas hashes, mas também números de revisão. Como adicionei alguns de meus próprios commits, todos os commits recebidos depois disso têm números de revisão diferentes do repositório central principal.

Números não significam nada. Você pode desconsiderá-los se eles o confundirem.

Eu atualizo o hg depois de puxar para mover automaticamente o meu marcador principal para o commit mais recente, mas não consegui encontrar uma maneira de fazer isso no TortoiseHG.

Eu não usei o TortoiseHG, mas hg pull -uvou fazer os dois pulle update.

Eu sempre usei o git antes, mas quero contribuir com o python, agora tenho que aprender mercurial e acho isso muito frustrante.

Tudo bem, muitos usuários do Mercurial sentem o mesmo sobre o Git (incluindo eu).

Mesmo quando Mercurial e Git são semelhantes, eles têm designs diferentes, talvez a diferença mais importante seja que, na modificação do Mercurial, a história não é tão flexível quanto no git (porque é meio desencorajado).

Resposta curta : não importa se você tem uma pequena quantidade de alterações, você ainda pode usar um ramo. Se você estiver pensando em excluir esse ramo, use um marcador para poder excluí-lo mais tarde e remover as alterações posteriormente.

Primeiro, tentando esclarecer algumas das coisas mencionadas:

• 1 e 4 são considerados ramificações porque toda vez que você confirma, você cria efetivamente uma ramificação sem nome (se houver outra confirmação ao mesmo tempo no seu repositório de origem / abençoado), que é tecnicamente uma ramificação. No método 4, você está criando uma nova "cabeça", enquanto no método 1 não está . Cabeças devem ser mescladas. Concordo que o método 1 é meio bobo, mas alguns parecem gostar ... de pequenos projetos, eu acho.

• Em relação ao método 2, não é que os galhos sejam pesados, é que eles são permanentes . Você não pode remover uma ramificação, a menos que use algo como a extensão da faixa. Mais uma vez, a filosofia de design da Mercurial não visa modificar a história (mas ficou melhor nisso).

• Em relação aos números de revisão , eles são apenas uma referência local e mais humanamente legível para você usar todos os comandos relacionados às revisões. Se você gosta de usar hashes, ainda pode fazer. Os números de revisão são apenas um atalho e são desconsiderados pelo Mercurial para qualquer operação interna entre repositórios diferentes.

Agora, para responder suas outras perguntas:

• Você pode verificar com quais cabeças você tem hg heads, se vir 2 ou mais cabeças em uma única ramificação nomeada, é preferível que elas sejam mescladas. Provavelmente é aí que está o seu marcador .
• Para se livrar de uma revisão que você acabou de fazer, você poderia fazer hg rollback, mas acho que esse não é o caso.
• Para excluir um marcador, basta hg bookmark --delete yourbookmark
• Você ficará feliz em saber que é fácil cortar galhos na história. Examine a extensão Rebase e a operação Strip .
• O Mercurial já vem com várias extensões, mas elas não são ativadas por padrão . Basta entrar em qualquer pasta e clicar com o botão direito do mouse em qualquer lugar para obter o menu de contexto do TortoiseHG, acessar Configurações Globais e depois Extensões: ativar a extensão MQ e a extensão Rebase. Isso não prejudica a compatibilidade entre repositórios, seja qual for.
• Agora que você está aqui, você pode:
  • Tira onde seu marcador começou (provavelmente isso resolve o seu problema)
  • Para uma visualização mais fácil, talvez você possa refazer as alterações à frente e depois retirá-las. Eu acabei de mencionar rebase porque pode ser algo útil para você em outra ocasião.

Além disso, no git, você pode ter "ramificações locais privadas" porque precisa enviá-las explicitamente e pode excluí-las posteriormente. No Mercurial, você pressiona tudo o que tem , no entanto, se quiser evitar isso, pode usar o recurso Fases e marcar um conjunto de revisões como secreto . Revisões secretas não serão pressionadas.

Finalmente, você não está fazendo nada de errado , mas lembre-se de que são apenas ferramentas diferentes construídas com mentalidades ligeiramente diferentes, que se resumem a: modificar histórico (git) ou não modificar histórico (hg). No Mercurial, é mais difícil dar um tiro no pé modificando a história (especialmente com as Fases) e é por isso que alguns gostam mais do que o git .

Acho que com o mercurial é mais fácil não se preocupar com galhos. Acabei de descobrir de onde na história quero editar e criar confirmações conforme necessário (também conhecido como ramos anônimos). Às vezes, os marcadores podem ser úteis se eu tiver que pular entre cabeças em diferentes contextos, mas na maioria das vezes eu não me importo com eles. Ramificações nomeadas são válidas para ramificações de longa duração (ramificações de correção de erros, ramificações de projeto), mas para correções de 1 ou 2 confirmações, elas não são a ferramenta certa para o trabalho.

O truque com ramificações anônimas é definir sua fase como "secreta" se você não quiser pressioná-las, ou seja, se deseja mantê-las locais. Se você não quer empurrá-los, mas você não quer mais commits com base nelas, você acabou de cometer um "--close-branch" em cima deles que significa que eles não aparecem mais na lista de 'cabeças' e mercurial parará de reclamar sobre várias cabeças nesse ramo.

Eu acho que podemos simplesmente usar o marcador em vez do ramo; continuaremos suportando o produto de qualquer maneira, e a fusão de dois ramos a longo prazo seria uma grande dor de cabeça.