Mercurial or Git as SCM for Java 12? “I see no pressing technical reasons to switch to Git”
Last month, the JDK team made a call for discussion in order to investigate a number of options for JDK source code management. But is it time to retire Mercurial in favor of Git? We talked to Thomas Stüfe, senior developer at SAP about all this and more.
With Project Skara, the JDK team wishes to investigate alternatives for JDK source code management, that’s been using Mercurial repositories since 2008.
Is it a good idea to “retire” Mercurial and choose Git instead? Chime in with a vote and see what Thomas Stüfe, senior developer at SAP has to say about this discussion.
Don’t miss the other two interviews about Project Skara:
JAXenter: What benefits would a move to another SCM -let’s say Git- have?
Thomas Stüfe: I see no pressing technical reasons to switch to Git. I work with both SCMs and to me, none has a clear lead in performance or functionality.
I think the only reason to switch to Git would be to make things easier for newcomers. Git is more mainstream than Mercurial, so more developers know it. And even though the concepts are very similar, Mercurial is different enough to be an annoying additional hurdle when starting out on the OpenJDK.
JAXenter: What problems would such a move cause?
Thomas Stüfe: A change like that is disruptive for existing contributors and for maintainers.
But in the end, I cannot see strong reasons for or against a switch to Git. I can live with whatever the community decides.
JAXenter: Is there any real alternative to Git as a replacement for Mercurial?
Thomas Stüfe: None that I think make sense.
JAXenter: How about the Review Process? Should it stay in the mailing lists or should it also be changed?
Thomas Stüfe: What would be the alternative? GitHub has been mentioned, so let’s take a hypothetical full-scale move to GitHub as a comparison.
I would much prefer staying on the mailing lists.
I have many concerns, but my biggest irk would be moving the review discussions away from mailing lists.
The mailing lists, with all their accumulated knowledge, are a treasure. The archives go back more than a decade and are indispensable for my work since a lot of our work is archaeological. You often need to dig through old threads to answer questions about the code base. Otherwise, you would have to reinvent the wheel and repeat old mistakes over and over again. Or be paralyzed, thus slowly fossilizing.
I am very hesitant to hand this content (well, future discussions) over to one external centralist provider. Mailing lists are democratic by nature: they belong to everyone. The mails can be viewed and processed and archived by everyone with whatever tools they please. I like it that way.
And then, I also believe that the communication platform you use influences your discussion style. Mailing lists lend themselves to carefully worded, precise communication if maybe a bit lengthy. Which is good. On GitHub or other hosters, I often observe a different style: more fluid and chat-like, but less precise and less information dense. Of course, I am not sure how much of that is caused by the platform. But still, I would much prefer staying on the mailing lists.