OpenJDK proposal: Dump Mercurial for Git

try {
threshold : 0, // You can set threshold on how close to the edge ad should come before it is loaded. Default is 0 (when it is visible).
forceLoad : false, // Ad is loaded even if not visible. Default is false.
onLoad : false, // Callback function on call ad loading
onComplete : false, // Callback function when load is loaded
timeout : 1500, // Timeout ad load
debug : false, // For debug use : draw colors border depends on load status
xray : false // For debug use : display a complete page view with ad placements
}) ;
catch (exception){
console.log(“error loading lazyload_ad ” + exception);

Single-repo OpenJDK projects would move from Mercurial to under a (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 , , and tools to Git.
  • Creation of a tool to translate between Mercurial and Git hashes.

Looking at alternatives to Mercurial was the subject of , 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.