3 ms·

Mercurial is great at an org with lots of junior devs, because people really have to try hard to mess things up compared to git. It's very bad if you want to at

by cmehdy 6y ago

Mercurial is great at an org with lots of junior devs, because people really have to try hard to mess things up compared to git. It's very bad if you want to attract people who feel comfortable with git alone (despite the fact that they'd do quite OK with hg), and it's especially bad if you are trying to fit with very standard types of CI, which for the most part have close to no support for mercurial at one point or another in the chain. And you might find that out a bit late into the process and end up paying a steep price ("Hello Gitlab? yeah I'm gonna have to set up a local secured Jenkins instance to do this and that before sending you the rest" type of thing) Recent-ish stackoverflow survey (2-3 years ago) also indicated that hg is used even less than zip files amongst devs, and significantly less than git, so market adoption is a big hurdle and anybody joining you will have to deal with this-thing-they-probably-don't-know and tooling that might not handle it (e.g. Xcode). However I think there's value in hg being training-wheels for git and a safe haven for a bunch of newbie devs, and we're talking about people who know and enjoy tech here so using any kind of vcs will at the very least enable your team to open up to more stuff. There's plenty of tooling and support to migrate to git if/when necessary, and IMHO Mercurial gets a much worse rep than it actually deserves.

nonbirithm 6y ago
As someone who only knows Git, needing to work on an open source project where you had no choice but to use Mercurial was a massive pain. I don't remember what happened exactly but coming from Git I managed to accidentally make a change somewhere but later needed to pull the latest changes and couldn't figure out the equivalent of rebasing and, when I got fed up with that, hard resetting for an hour. In the end I gave up and used git-hg to fork the repository, losing the ability to merge upstream, because I wanted to get things done and did not want the requirement to learn an entirely new VCS just for this one repository to hold me back. But that's coming from me, who doesn't understand how Mercurial is supposed to be used. I felt happy when BitBucket announced they were sunsetting Mercurial, because of the miserable experience I had with that one single time and the fact that it would mean that all of the repository owners who forced you to learn Mercurial to contribute to their code would have no choice but to switch their repos to Git. But because I don't know any better I guess I don't understand what was being lost fully by losing Mercurial.
- cmehdy 6y ago
  It's quite valid. I think the biggest hurdle is noticing that when you mess up hard with git the hurdles are affecting everyone down the line, possibly irreversibly. If you mess up with mercurial, the hurdles are affecting YOU locally really hard, possibly irreversibly. That's probably why it's the main reason git people hate hg and hg people are confused about git, until they really mess up, and outside people view hg as much more limited than git. I don't really have a side in any metaphorical battle because I've had to set up CI/CD for a mix of git and mercurial, but simply giving in to the social pressure of the tech world I've become more acquainted with git over time than with hg as a junior and I can see value in both. However at a higher level (organization level especially), it's critically important to look at the trade-off that the choice gives you. I'm trying to be objective here in saying that unless mercurial gains more traction in the world, fortunately or unfortunately you should stick heavily with git.

by cmehdy 6y ago

nonbirithm 6y ago

As someone who only knows Git, needing to work on an open source project where you had no choice but to use Mercurial was a massive pain. I don't remember what happened exactly but coming from Git I managed to accidentally make a change somewhere but later needed to pull the latest changes and couldn't figure out the equivalent of rebasing and, when I got fed up with that, hard resetting for an hour. In the end I gave up and used git-hg to fork the repository, losing the ability to merge upstream, because I wanted to get things done and did not want the requirement to learn an entirely new VCS just for this one repository to hold me back. But that's coming from me, who doesn't understand how Mercurial is supposed to be used. I felt happy when BitBucket announced they were sunsetting Mercurial, because of the miserable experience I had with that one single time and the fact that it would mean that all of the repository owners who forced you to learn Mercurial to contribute to their code would have no choice but to switch their repos to Git. But because I don't know any better I guess I don't understand what was being lost fully by losing Mercurial.

cmehdy 6y ago
It's quite valid. I think the biggest hurdle is noticing that when you mess up hard with git the hurdles are affecting everyone down the line, possibly irreversibly. If you mess up with mercurial, the hurdles are affecting YOU locally really hard, possibly irreversibly. That's probably why it's the main reason git people hate hg and hg people are confused about git, until they really mess up, and outside people view hg as much more limited than git. I don't really have a side in any metaphorical battle because I've had to set up CI/CD for a mix of git and mercurial, but simply giving in to the social pressure of the tech world I've become more acquainted with git over time than with hg as a junior and I can see value in both. However at a higher level (organization level especially), it's critically important to look at the trade-off that the choice gives you. I'm trying to be objective here in saying that unless mercurial gains more traction in the world, fortunately or unfortunately you should stick heavily with git.