OpenJDK proposal: Dump Mercurial for Git

Proposal would migrate single-repo OpenJDK projects from Mercurial to Git for smaller repo sizes and superior tooling

OpenJDK proposal: Dump Mercurial for Git
Amber Avalona (CC0)

Single-repo OpenJDK projects would move from Mercurial to Git version control under a JDK Enhancement Proposal (JEP) being reviewed by Mark Reinhold, chief architect of the Java platform group at Oracle.

A primary motivation behind the effort is reducing the size of version control metadata, which would preserve disk space and reduce clone size. The proposal notes that the .git directory of the jdk/jdk repo is approximately 300 MB with Git while the .hg directory is around 1.2 GB with Mercurial, depending on the version of Mercurial in use.

Also, the proposal cites that there are many more tools for interacting with Git than Mercurial, with all text editors and most IDEs integrating with Git and many desktop clients also supporting it. Available hosting also is a motivator, with many options available for hosting Git repos, whether self-hosted or hosted as a service.

The plan cites these goals for the migration:

  • Preserving version history, including tags.
  • Reformatting commit messages according to Git best practices.
  • Porting the jcheck, webrev, and defpath tools to Git.
  • Creation of a tool to translate between Mercurial and Git hashes.

Looking at alternatives to Mercurial was the subject of Project Skara, an effort that came to light a year ago. Not everyone was on board with the new proposal, at least immediately. One objector cited issues with project conversion times, developers having to readjust workflows, and refitting of development pipelines.

Migration of multi-repository OpenJDK projects, such as the JDK 8 updates project, is not part of the proposal. Those projects could move to Git if they consolidate into a single repo. There will be no change from the Java Bug System, either.

Proponents have no plans to address the question of whether OpenJDK Git repos will be self-hosted or hosted by an external provider; that issue will be the topic of a future JEP. Nor does the JEP propose changes to the current JDK development process, although the plan itself would enable such changes.

Copyright © 2019 IDG Communications, Inc.

How to choose a low-code development platform