One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
I also used Mercurial for a long time. It has all the same mindset, that everything is decentralized and your local repository can synchronise with a remote one. It also uses acyclic graph to represent your history.
To sumarize key diffs :
git branch are just a reference to a commit (called light branches/ bookmarks in mercurial), where as in mercurial your branch and your commit are glued together with a name (called heavy/named branches). This has some impacts i'll explain below...
git allows to change remote history, whereas in mercurial you can only change your local history...
mercurial named branches, comes with what is called phases that are status attached to your local version of your branch and for example allows for good rebase defaults. it's impossible in mercurial to rebase in the wrong order (rebase remote on your local), you can only rebase your local to your remote. this evoids rooky mistakes on rebase commands.
there is no stagging area in mercurial, so if you want to only add a part of a file to your next commit, you have to use tools like interactive commits.
there is no patch system in mercurial, but you have a plugin called queues that are a mix of patches and stash. It's definitely easier to understand for new users than the patch system of git.
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
there is a bundle file format, that can carry around commits and branch names safely between repositories (in fact, I used it to collaborate before BitBucket was there). This file format enables me to collect the homeworks from my students with the certainty that they will not be able to mess up with my repository. I'm not sure if that can be done in git with the same level of peace of mind.
And as for the rebase thing, there was a solution in the works a few years ago: I don't know now if it has been deployed.
The staging area is maybe the only thing in git that I find remotely useful, sometimes. But I went on for years without it, and sometimes it just gets in the way.
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.
That's interesting, I wondered how mercurial compares.
Do you have examples of common use cases that are straightforward in Mercurial heaven and quircky in git?
I also used Mercurial for a long time. It has all the same mindset, that everything is decentralized and your local repository can synchronise with a remote one. It also uses acyclic graph to represent your history.
To sumarize key diffs :
Also:
And as for the rebase thing, there was a solution in the works a few years ago: I don't know now if it has been deployed.
The staging area is maybe the only thing in git that I find remotely useful, sometimes. But I went on for years without it, and sometimes it just gets in the way.
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.