6 ms·

Bitbucket dropped Mercurial support in 2020: https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket https://bitbucket.org/blog/sunsetting-mercuria

Bitbucket dropped Mercurial support in 2020: https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket https://bitbucket.org/blog/sunsetting-mercurial-support-in-b... I just don't think there is good RoI for implementing Mercurial support. It really isn't about the interface (which I think most people agree hg is better than git). It's just the network effect: most projects use git so everybody learns git and they don't want to learn another tool even if it's better in some ways. At the end of the day, once you pay a higher upfront cost to learn the ~5 git invocations you need, your daily productivity between using git and hg is probably the same. Google and Facebook is different: they have a unique use-case and scale, and massive internal tooling teams supporting their use-cases. Also, as an employee, you're probably more open to different VCS systems because if you learn hg at Facebook, you're learning it on company time whereas if you learn for an open source project, you're learning it on your time.

dehrmann 3y ago
> It's just the network effect It's almost like qwerty vs dvorak in that regard, except git and mercurial were contemporaries. Mercurial isn't quite good enough to displace git, and git has Linus as a promoter which was all it needed to be the leader. That said, I agree that the network effect of having just one is more valuable than mercurial's ergonomics (which could still use a good branch story).
- acdha 3y ago
  Mercurial also missed the window on performance and safety. If you started using it around 2009 or so, Hg was notably slower for daily use and a lot of people recommended using extensions to match Git features but those extensions were not stable (Hg and RCS are the only VCSes I’ve seen require data to be recovered from a backup due to normal usage). There’s a meme that Git is hard to use but I think it’s conflating the challenges of getting used to version control at all, distributed version control, and any specific tool. I watched a number of developers do that and it was about as much work to go from SVN to either Git or Mercurial, and if they learned the other DVCS it was always easier since they were mapping concepts rather than learning them for the first time. The marginal returns on productivity weren’t worth switching in most cases so it tended to come down to Git being so much faster and, as network effects kicked in, easier to host.
  - compiler-guy 3y ago
    > There’s a meme that Git is hard to use but I think it’s conflating the challenges of getting used to version control at all, distributed version control, and any specific tool That may be the case for some people, but far from all. Many people who started with cvs or even rcs and have moved on to the newer things as they have appeared still find got annoying and unintuitive. Especially compared to Mercurial. You use it, because it is now the standard, but you are also very aware of how much cleaner and easier other systems have been.
    - acdha 3y ago
      My experience was comparing multople people who started with Mercurial and later learned Git, and had basically all of what people term “Git problems” with Hg because the hard part was thinking about distributed version control. I’m not saying Git is perfect but simply that it’s hard to separate the difficulties from learning new concepts and working styles from the tool.
  - mrweasel 3y ago
    > Hg was notably slower for daily use There was an interview with Linus Torvalds at some point where he points out that Mercurial was one of the tools he tried using to replace Bitkeeper, but found it to be much to slow. Has he tells it in the interview he later learned that the slowness he experienced was due to a bug in Mercurial and had that not been there, git might never have happened. If that's true it a little sad, but I also wonder if many of us might still be on SVN, Perforce or whatever. Git, by being a product of Linus brought a lot of focus on Git. Bitkeeper never got the same attention, that was a commercial product, but being used for kernel development didn't see to promote it as much as I'd expect.
    - HelloNurse 3y ago
      Bitkeeper was more or less like Subversion, fast, expensive and slightly complicated; you seem to overestimate the relevance and influence of Linux kernel use for the average corporate decision maker who doesn't care about Linux, doesn't care about distributed VC, doesn't care about performance (because it only affects peons), doesn't like to spend money and doesn't like bleeding edge tools.
otabdeveloper4 3y ago
> It's just the network effect No, it isn't. Git is unopinionated and doesn't try to shove some half-baked idea of "best practices" and "you're doing it wrong" down your throat. This means there is no friction in adopting Git at the workplace.
- postexitus 3y ago
  my git reset --hard disagrees
- RyanHamilton 3y ago
  >>This means there is no friction in adopting Git at the workplace. It could be said that the virality (network effect) is higher as it spreads easier. Anything is opinionated it's just whether or not those opinions align with your internal values. It appears git aligns with you.

dehrmann 3y ago

> It's just the network effect It's almost like qwerty vs dvorak in that regard, except git and mercurial were contemporaries. Mercurial isn't quite good enough to displace git, and git has Linus as a promoter which was all it needed to be the leader. That said, I agree that the network effect of having just one is more valuable than mercurial's ergonomics (which could still use a good branch story).

acdha 3y ago
Mercurial also missed the window on performance and safety. If you started using it around 2009 or so, Hg was notably slower for daily use and a lot of people recommended using extensions to match Git features but those extensions were not stable (Hg and RCS are the only VCSes I’ve seen require data to be recovered from a backup due to normal usage). There’s a meme that Git is hard to use but I think it’s conflating the challenges of getting used to version control at all, distributed version control, and any specific tool. I watched a number of developers do that and it was about as much work to go from SVN to either Git or Mercurial, and if they learned the other DVCS it was always easier since they were mapping concepts rather than learning them for the first time. The marginal returns on productivity weren’t worth switching in most cases so it tended to come down to Git being so much faster and, as network effects kicked in, easier to host.
- compiler-guy 3y ago
  > There’s a meme that Git is hard to use but I think it’s conflating the challenges of getting used to version control at all, distributed version control, and any specific tool That may be the case for some people, but far from all. Many people who started with cvs or even rcs and have moved on to the newer things as they have appeared still find got annoying and unintuitive. Especially compared to Mercurial. You use it, because it is now the standard, but you are also very aware of how much cleaner and easier other systems have been.
  - acdha 3y ago
    My experience was comparing multople people who started with Mercurial and later learned Git, and had basically all of what people term “Git problems” with Hg because the hard part was thinking about distributed version control. I’m not saying Git is perfect but simply that it’s hard to separate the difficulties from learning new concepts and working styles from the tool.
- mrweasel 3y ago
  > Hg was notably slower for daily use There was an interview with Linus Torvalds at some point where he points out that Mercurial was one of the tools he tried using to replace Bitkeeper, but found it to be much to slow. Has he tells it in the interview he later learned that the slowness he experienced was due to a bug in Mercurial and had that not been there, git might never have happened. If that's true it a little sad, but I also wonder if many of us might still be on SVN, Perforce or whatever. Git, by being a product of Linus brought a lot of focus on Git. Bitkeeper never got the same attention, that was a commercial product, but being used for kernel development didn't see to promote it as much as I'd expect.
  - HelloNurse 3y ago
    Bitkeeper was more or less like Subversion, fast, expensive and slightly complicated; you seem to overestimate the relevance and influence of Linux kernel use for the average corporate decision maker who doesn't care about Linux, doesn't care about distributed VC, doesn't care about performance (because it only affects peons), doesn't like to spend money and doesn't like bleeding edge tools.

otabdeveloper4 3y ago

> It's just the network effect No, it isn't. Git is unopinionated and doesn't try to shove some half-baked idea of "best practices" and "you're doing it wrong" down your throat. This means there is no friction in adopting Git at the workplace.

postexitus 3y ago
my git reset --hard disagrees
RyanHamilton 3y ago
>>This means there is no friction in adopting Git at the workplace. It could be said that the virality (network effect) is higher as it spreads easier. Anything is opinionated it's just whether or not those opinions align with your internal values. It appears git aligns with you.