Eu meio que matei o Mercurial na Mozilla

Artigo original ↗ Discussão no Hacker News ↗

A mudança da Mozilla do Mercurial para Git e GitHub é enquadrada como parte de uma transição mais ampla em que o Mercurial, apesar de uma CLI mais amigável e recursos fortes, foi superado pelos efeitos de rede do Git, pelo ecossistema de ferramentas e pelo apoio de gigantes como Microsoft, Meta e Google. Os comentadores revisitam por que hosts anteriores do Mercurial, como o Bitbucket, o abandonaram, como grandes empresas agora envolvem sistemas personalizados (Sapling, jj, Perforce, Piper) em torno de modelos semelhantes ao Git, e por que muitos desenvolvedores ainda acham a UX do Git confusa em comparação com o Mercurial. O fio também avalia a ergonomia fraca de code review do GitHub e os riscos de lock-in de a Mozilla depender de uma plataforma controlada pela Microsoft, contra os benefícios práticos de se alinhar com a infraestrutura dominante para colaboração em código aberto.

O declínio do Mercurial e os efeitos de rede

  • Muitos veem o Mercurial como efetivamente “acabado”: o Bitbucket removeu o hg, os principais hosts são só Git, e a adoção nova do Mercurial é mínima.
  • Outros contrapõem que o Mercurial ainda é mantido, roda em Python 3, tem componentes em Rust e ganha recursos como Changeset Evolution.
  • O consenso: o Git venceu em grande parte por efeitos de rede (kernel Linux, GitHub, ecossistema de ferramentas). Depois que as pessoas aprendem Git, trocar parece ter pouco retorno, mesmo que hg seja melhor.

Plataformas de hospedagem e o “HgHub” ausente

  • O Bitbucket é repetidamente citado como o “hghub” de fato que começou só com hg, depois adicionou Git e então removeu hg.
  • Alguns chamam a remoção do Mercurial de míope; outros argumentam que o uso de hg havia caído abaixo de 1% dos novos usuários e que sustentar dois sistemas VCS não valia a pena.
  • SourceHut e Heptapod são mencionados como hosts que ainda são amigáveis ao Mercurial.

Stacks de VCS de grandes empresas (Meta, Google, Microsoft)

  • A Meta historicamente escalou o Mercurial; agora expõe o Sapling, um sistema derivado do Mercurial com compatibilidade com Git. Internamente, as pessoas ainda usam comandos no estilo hg, mas o Sapling open source divergiu e é mais um VCS próprio.
  • A interoperabilidade do Sapling com Git é descrita como útil, mas ainda áspera (problemas com LFS, atrito em force-push, casos-limite em repositórios grandes).
  • O Google colocou sua monorepo (Piper) na frente de um cliente baseado em Mercurial porque o hg tinha um protocolo de rede real; há trabalho em andamento para substituir isso por jj (Jujutsu), que pega ideias de UX do hg enquanto interoperabiliza com o armazenamento Git.
  • A Microsoft investiu pesado para fazer o Git escalar para repositórios enormes e clones parciais.

Git vs Mercurial em UX e filosofia

  • Muitos elogiam a CLI mais limpa do hg, a terminologia consistente, boas GUIs no Windows (por exemplo, TortoiseHg) e recursos como revsets e phases.
  • Muitos também criticam os comandos confusos do Git, flags perigosas e conceitos idiossincráticos (index/staging area, stash, reset --hard).
  • Contraponto: boa parte da dificuldade percebida é aprender conceitos de VCS distribuído, não o Git especificamente; uma vez entendido, o Git é poderoso e difícil de realmente perder dados com ele (reflog, etc.).
  • Divergência histórica: o Git abraçou cedo a reescrita de histórico; o Mercurial era filosoficamente cauteloso, o que levou a ferramentas como MQ e depois modelos mais complexos (phases, evolve).

Fluxos de code review e a UI do GitHub

  • Há forte crítica ao review de PRs do GitHub para fluxos sérios/empilhados: má gestão de múltiplas versões, perda de contexto após rebases, suporte fraco a range-diff, comentários limitados em linhas inalteradas e rounds de review multi-etapa complicados.
  • Sistemas como Gerrit e Phabricator são elogiados por diffs por commit/empilhados e pela evolução clara entre versões de patches.
  • Ferramentas de terceiros (Graphite, CodeApprove, Reviewable) tentam adicionar melhores workflows de review e de diffs empilhados sobre o GitHub.

Repositórios grandes, monorepos e binários

  • A história do Git com monorepos é vista como historicamente fraca (submodules, sparse checkout, partial clone chegaram tarde). Alguns argumentam que o Git não é uma boa escolha para monorepos no estilo Google sem muita ferramenta adicional.
  • Outros sustentam que o Git serve bem para repositórios grandes abaixo da “escala Google” e que monorepos expõem principalmente problemas de processo/organização.
  • Diz-se que desenvolvimento de jogos e ASIC depende do Perforce para binários grandes; Git LFS é amplamente suportado, mas chamado de desajeitado e pesado em termos de workflow em comparação com o tratamento de largefile do Mercurial.

Alternativas e direções futuras

  • Várias pessoas gostam da abordagem tudo-em-um do Fossil (VCS + rastreador de issues + UI web) e da implantação em um único binário.
  • Pijul é mencionado como um VCS avançado baseado em patches que alguns esperam que se torne mais comum.
  • Jujutsu é destacado como um VCS promissor compatível com Git, com log de operações e undo embutido, visando modernizar a UX de VCS além de Git e Mercurial.

A mudança da Mozilla para Git/GitHub

  • Muitos aceitam a troca da Mozilla para Git como pragmática, dadas as realidades do ecossistema e a dependência interna de ferramentas Git (por exemplo, git-cinnabar como ponte).
  • Alguns argumentam que escolher GitHub especificamente entra em conflito com os valores declarados da Mozilla em torno de descentralização e torna a contribuição dependente de uma conta controlada pela Microsoft.