Más o menos maté a Mercurial en Mozilla

Artículo original ↗ Discusión en Hacker News ↗

El paso de Mozilla de Mercurial a Git y GitHub se enmarca como parte de un cambio más amplio en el que Mercurial, pese a una CLI más amigable y funciones potentes, ha sido eclipsado por los efectos de red de Git, su ecosistema de herramientas y el respaldo de gigantes como Microsoft, Meta y Google. Los comentaristas revisan por qué alojamientos anteriores de Mercurial como Bitbucket lo abandonaron, cómo las grandes empresas ahora envuelven sistemas personalizados (Sapling, jj, Perforce, Piper) alrededor de modelos parecidos a Git, y por qué muchos desarrolladores aún encuentran confusa la UX de Git en comparación con Mercurial. El hilo también sopesa la mala ergonomía de la revisión de código en GitHub y los riesgos de dependencia de Mozilla de una plataforma propiedad de Microsoft frente a los beneficios prácticos de alinearse con la infraestructura dominante para la colaboración en software libre.

El declive de Mercurial y los efectos de red

  • Muchos ven a Mercurial como efectivamente “acabado”: Bitbucket dejó de dar soporte a hg, los grandes hospedajes son solo Git, y la adopción nueva de Mercurial es mínima.
  • Otros responden que Mercurial sigue mantenido, funciona con Python 3, tiene componentes en Rust y gana funciones como Changeset Evolution.
  • El consenso: Git ganó en gran medida por efectos de red (el kernel de Linux, GitHub, el ecosistema de herramientas). Una vez que la gente aprende Git, cambiar parece tener poco retorno aunque hg sea mejor.

Plataformas de alojamiento y el “HgHub” que falta

  • Bitbucket se cita repetidamente como el “hghub” de facto que empezó siendo solo hg, luego añadió Git y después eliminó hg.
  • Algunos califican la eliminación de Mercurial de miope; otros sostienen que el uso de hg había caído por debajo del 1% de los usuarios nuevos y que mantener dos sistemas VCS no valía la pena.
  • SourceHut y Heptapod se mencionan como alojamientos que aún son favorables a Mercurial.

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

  • Meta históricamente escaló Mercurial; ahora expone Sapling, un sistema derivado de Mercurial con compatibilidad con Git. Internamente, la gente sigue usando comandos estilo hg, pero el Sapling de código abierto se ha desviado y ya es más bien su propio VCS.
  • La interoperabilidad de Sapling con Git se describe como útil pero aún tosca (problemas con LFS, fricción al hacer force-push, casos límite en repositorios grandes).
  • Google puso una capa frontal a su monorepo (Piper) con un cliente basado en Mercurial porque hg tenía un protocolo real de red; se está trabajando para reemplazar esto con jj (Jujutsu), que toma ideas de UX de hg mientras interopera con el almacenamiento de Git.
  • Microsoft invirtió mucho para hacer que Git escalara para repos enormes y clones parciales.

Git vs Mercurial: UX y filosofía

  • Muchos elogian la CLI más limpia de hg, la terminología consistente, las buenas GUIs para Windows (p. ej., TortoiseHg) y funciones como revsets y phases.
  • Muchos también critican los comandos confusos de Git, los flags peligrosos y los conceptos idiosincráticos (índice/staging area, stash, reset --hard).
  • Contrapunto: gran parte de la dificultad percibida es aprender conceptos de VCS distribuidos, no Git en particular; una vez entendido, Git es potente y es difícil perder datos de verdad con él (reflog, etc.).
  • Divergencia histórica: Git abrazó pronto la reescritura de historial; Mercurial fue filosóficamente más cauteloso, lo que llevó a herramientas como MQ y más tarde a modelos más complejos (phases, evolve).

Flujos de revisión de código y la interfaz de GitHub

  • Fuerte crítica a la revisión de PR en GitHub para flujos serios/apilados: mala gestión de múltiples versiones, pérdida de contexto tras los rebases, soporte débil para range-diff, comentarios limitados en líneas sin cambios y rondas múltiples de revisión incómodas.
  • Sistemas como Gerrit y Phabricator son elogiados por diffs por commit/apilados y por mostrar claramente la evolución entre versiones de parches.
  • Herramientas de terceros (Graphite, CodeApprove, Reviewable) intentan añadir mejores flujos de revisión y diffs apilados sobre GitHub.

Repositorios grandes, monorepos y binarios

  • La historia de Git con los monorepos se ve como históricamente débil (submódulos, sparse checkout, partial clone llegaron tarde). Algunos sostienen que Git no encaja bien con monorepos al estilo Google sin herramientas pesadas.
  • Otros mantienen que Git está bien para repos grandes por debajo de “escala Google” y que los monorepos sobre todo exponen problemas de proceso/organización.
  • Se dice que el desarrollo de videojuegos y ASIC depende de Perforce para binarios grandes; Git LFS está ampliamente soportado, pero se lo llama torpe y pesado en el flujo de trabajo comparado con el manejo de largefile de Mercurial.

Alternativas y direcciones futuras

  • A varias personas les gusta el enfoque todo-en-uno de Fossil (VCS + gestor de incidencias + interfaz web) y su despliegue de un solo binario.
  • Se menciona Pijul como un VCS avanzado basado en parches que algunos esperan que se vuelva más común.
  • Jujutsu se destaca como un VCS compatible con Git prometedor, con un registro de operaciones y deshacer integrado, con la intención de modernizar la UX de los VCS más allá de Git y Mercurial.

El paso de Mozilla a Git/GitHub

  • Muchos aceptan el cambio de Mozilla a Git como pragmático dadas las realidades del ecosistema y la dependencia interna de herramientas de Git (por ejemplo, git-cinnabar como puente).
  • Algunos argumentan que elegir GitHub específicamente entra en conflicto con los valores declarados de Mozilla sobre la descentralización y hace que contribuir dependa de una cuenta controlada por Microsoft.