Passionate developer in Java and Scala. And sometimes, something else. A few months per year, someone calls me "professor". CoFounder of Scala By The Lagoon @scalagoon
Branches is the biggest difference. The "branch is a property of the commit" model of mercurial is much, much easier to understand compared to the "branch is the label of the graph head". The resulting workflow is simpler and less error-prone, especially for the newbies.
Command names and ergonomy is much higher in mercurial, since it was deliberately thought and chosen. Git was written in a hurry because there was a need (Linus parted ways with the sponsor of the previous kernel's VCS) and focused on functionality in Linus' terms.
Collaborating without a central server is very easy: just bundle your changes and share them on Skype (well, I used to do like that some 15 yrs ago). There is no way you can mess up a coworker's repo: it's very difficoult to break an hg repository.
Mechanic by trade, software dev because it's fun as heck. And, well, it will be nice to WFH when I decide my body has had enough. No commute, A/C, less silica glistening in the early morning air!
By enforcing pull request to branch head only, enforcing reviews, no one is going to break my repo unless I press the big red "Do Not Push" button myself. That said, hg does sound like it would be a nice experience.
I'll be sticking with git for its ubiquity and GitHub's integration with...everything lol. I will, however, try out Mercurial when free time permits. I am more than a bit curious.
Passionate developer in Java and Scala. And sometimes, something else. A few months per year, someone calls me "professor". CoFounder of Scala By The Lagoon @scalagoon
The sad state of the affairs is that, after losing the JDK, that was one of the last "high profile" repositories that still used mercurial, I think it is sliding (not even slowly) towards irrelevance.
It is very very unlikely that the "gitops" ecosystem will care to add an option for the source repository tool. It will, however, become a problem sometime in the future; when it happens, a replacement will probably need to be something far for modern and robust even than Mercurial.
An interesting candidate for this role is Pijul. It has a well thought theory behind it, a quite good execution (that is, is dogfooding a log), and a hard look back at the history of the VCS toolset. With a heavy heart, I suggest you that your valuable free time will be better spent experimenting with that.
I'll continue to use mercurial in my university classes, to expose the students to something good.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Branches is the biggest difference. The "branch is a property of the commit" model of mercurial is much, much easier to understand compared to the "branch is the label of the graph head". The resulting workflow is simpler and less error-prone, especially for the newbies.
Command names and ergonomy is much higher in mercurial, since it was deliberately thought and chosen. Git was written in a hurry because there was a need (Linus parted ways with the sponsor of the previous kernel's VCS) and focused on functionality in Linus' terms.
Collaborating without a central server is very easy: just bundle your changes and share them on Skype (well, I used to do like that some 15 yrs ago). There is no way you can mess up a coworker's repo: it's very difficoult to break an hg repository.
By enforcing pull request to branch head only, enforcing reviews, no one is going to break my repo unless I press the big red "Do Not Push" button myself. That said, hg does sound like it would be a nice experience.
I'll be sticking with git for its ubiquity and GitHub's integration with...everything lol. I will, however, try out Mercurial when free time permits. I am more than a bit curious.
The sad state of the affairs is that, after losing the JDK, that was one of the last "high profile" repositories that still used mercurial, I think it is sliding (not even slowly) towards irrelevance.
It is very very unlikely that the "gitops" ecosystem will care to add an option for the source repository tool. It will, however, become a problem sometime in the future; when it happens, a replacement will probably need to be something far for modern and robust even than Mercurial.
An interesting candidate for this role is Pijul. It has a well thought theory behind it, a quite good execution (that is, is dogfooding a log), and a hard look back at the history of the VCS toolset. With a heavy heart, I suggest you that your valuable free time will be better spent experimenting with that.
I'll continue to use mercurial in my university classes, to expose the students to something good.