New candidate JEP: 357: Migrate from Mercurial to Git
shade at redhat.com
Mon Jul 15 18:52:02 UTC 2019
On 7/15/19 7:54 PM, mark.reinhold at oracle.com wrote:
Unfortunately, this JEP only discusses the advantages, and does not discuss the disadvantages of
performing this move.
The disadvantages, off the top of my head:
*) Conversion takes time and effort for all projects, including those developed outside of
mainline: Amber, Loom, Panama, Portola, Shenandoah, Valhalla to name a few;
*) Developers who are already quite constrained to deliver things with 6 months pace would have to
re-adjust their workflows, some would need re-training to Git, many would have to accept the
temporary productivity losses, and/or modify their delivery schedules;
*) Downstream builders would need to refit their pipelines after the move -- and there are lots of
Additionally, not addressed:
*) Existing hgupdater links in JBS would have to be updated, or they would break;
*) External links to hg.o.j.n -- that were deemed to be permalinks to the JDK source code, perhaps
with lots of wishful thinking involved -- would break;
*) There are improvements to Mercurial that can make the conversion advantages less appealing. For
example, clonebundles that I pointed out multiple times over the year (and Mark promised to deliver,
at OpenJDK Committers Workshop in February 2019) is still not enabled:
https://bugs.openjdk.java.net/browse/JDK-8211383. Instead, we have "Alternatives: Keep using
*) The claim that "There are many more tools for interacting with Git than Mercurial" look dubious.
For the tools I use from that list: IntelliJ, NetBeans, Atom are supporting Mercurial as well.
AFAIU, JEPs are supposed to capture the pros and cons, and provide extended background for
discussion for the changes that have wide area of effect. Alas, the JEP 357 does not look to be in
that state at the moment.
More information about the discuss