6 ms·

Is there a reason why they used Mercurial as opposed to git? Did it provide some benefit?

by mgd 3y ago

vardump 3y ago
Probably tooling and developer mindshare. Might not have much to do with git vs Mercurial technical merits.
- zilti 3y ago
  "developer mindshare" has become one of the most bullshit reasons to use something.
  - j1elo 3y ago
    "developer mindshare" usually equals better or at least more support. Which is not at all a bullshit reason to use something.
  - sshine 3y ago
    For that reason alone, yes. But not for the reasons that correlate, such as education, tooling.
- Espressosaurus 3y ago
  Yeah. From a technical standpoint Git is a lot worse in a lot of ways. From an ease-of-use standpoint it's about as much worse as it's possible to be. Still, with Linux behind it, Git won the DVCS wars. Mercurial became an also-ran and now almost nobody uses it. Too bad. We'll need something new and innovative to come out and rid us of constant blogs explaining how Git works because it's too hard to understand how to make it do the things you want it to do. I've been using Git for about 7 years now (5 exclusively) and I know how to use it, but I still have to look things up occasionally because its UI is trash and non-obvious. I didn't have that problem with Mercurial. There, I knew the verb and the built-in help was sufficient to get me where I wanted to go. Worse is better wins again.
  - TerrifiedMouse 3y ago
    > We'll need something new and innovative to come out and rid us of constant blogs explaining how Git works because it's too hard to understand how to make it do the things you want it to do. Read about Jujutsu awhile back. https://news.ycombinator.com/item?id=30398662 https://news.ycombinator.com/item?id=30398662
  - pptr 3y ago
    I really enjoy the simplicity of Googles internal repo (piper). I am quite surprised that no open source variant has been created yet (that I'm aware of).
    - Ygg2 3y ago
      How does piper work?
  - WesolyKubeczek 3y ago
    > Yeah. From a technical standpoint Git is a lot worse in a lot of ways. From an ease-of-use standpoint it's about as much worse as it's possible to be. Ten years ago, when I had started to use git after having used both Subversion and Mercurial, I noticed one thing. Git was FAST. On repositories of the same size, git was blowing Mercurial out of the water and running circles around it, that's how fast it was. It was FAST and it fucking got out of my way and let me work. I don't know the inner workings of either and academic advantages of Mercurial, but I know for a fact it had been a dog and its move to Python 3 had been disastrous. So whichever technical or UX advantages Mercurial might have, I simply don't care anymore.
    - geraldwhen 3y ago
      Younguns may forget or never have experienced branching an svn repo. It used to literally take hours. Then git-svn was born, and you could branch instantly. This was such an obvious improvement that all future repos moved to git.
      - 3y ago
hiddencost 3y ago
https://wiki.mozilla.org/VersionControlSummit2006 https://wiki.mozilla.org/VersionControlSummit2006
dale_glass 3y ago
Mercurial came out about a week after Git did. I've not used it in a long time but I recall that it was a lot less confusing than Git to use. But Git definitely won the war, and Mercurial has been disappearing little by little.
gtsteve 3y ago
The two came out at roughly the same time and for the first few years it wasn't really obvious which was better. Personally, I chose Mercurial to start with, because I liked the Windows tooling available and it felt a lot more like Subversion, which is what I used previously. However, Git won the mindshare war in the end, so I moved over to that.
- santiagobasulto 3y ago
  Happened the SAME thing to me. Mercurial felt more natural than git. Back then, Github allowed you to choose the VC and Mercurial and Git were available, I'd always choose Mercurial. I was also using Google Code that allowed for mercurial as well. Ahhhh, thanks for brining back those memories.
  - antod 3y ago
    > Github allowed you to choose the VC and Mercurial and Git were available You're not thinking about BitBucket are you? I thought Github was always git only?
    - pseudalopex 3y ago
      GitHub started with Git and added Subversion. Never Mercurial.
      - antod 3y ago
        Oh that's right - I'd forgotten about that april fools joke that wasn't. It was just client compatibility right - the backend was still git from memory? What I mean was that it wasn't like Bitbucket where you chose whether you wanted git or hg for starting your project.
        innocenat 3y ago
        BitBucket was Mercurial-only for quite some times before they added Git (when it was obvious that Git was winning). I think Google Code provide both from the early day (along with Subversion), and maybe also SourceForge.
deleted 3y ago
[deleted]
bsder 3y ago
Yeah, the mental model of Mercurial is way better. Unfortunately, GitHub got VC funding and caused network effects to kick in. Git came along with GitHub as a parasite much like C came along as a parasite with Unix.
- adastra22 3y ago
  I'm a huge critic of git, but I think it won out on merits. Git was used by the Linux kernel, and therefore from the beginning scaled better to much larger projects than other DVCS systems.
  - Ygg2 3y ago
    Except it doesn't scale to codebases the size of Facebook and Google.
    - jahav 3y ago
      MS stores windows codebase in a single repo (https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/ https://devblogs.microsoft.com/bharry/the-largest-git-repo-o...). 300GB. I don't really see a benefit of having all code of an org in a single repo. Single product, sure. But whole company? Why. Not to mention, these are serious outliers. From security standpoint, it doesn't seem great, from practical side, it's not great (bandwidth cost ect).
      - Ygg2 3y ago
        There was similar push by Facebook to improve Mercurial perf and they showed some impressive advantage over Git. It seems it was abandoned eventually for Git.
    - dig1 3y ago
      > Except it doesn't scale to codebases the size of Facebook and Google. Actually, it scales well with large codebases, but the monorepo mental model pushed by FB/Google doesn't match the git workflow model. Git repo design is for a concrete entity: a single tool, binary, service, kernel, whatever. When you start bashing in multiple unrelated projects where you try to have various per-project versioning schemas, it becomes a mess.
Xenoamorphous 3y ago
I wonder how much the “victory” of git vs mercurial was influenced by having a big name like Linus Torvalds behind it.
- VMG 3y ago
  big name and big speed - I distinctly remember how slow "mercurial" was when git started dominating
  - ygra 3y ago
    Since then both had lots of optimizations put into it to work outside their original intended domains. Facebook did a lot to make Mercurial performance on very large repositories tenable. Microsoft did the same for Git to allow their Windows developers to work with Git, which apparently was initially not able to do common operations at all at acceptable speed. But those are big company problems and I suspect the caveats, tradeoffs and solutions matter a lot less for the 99 % of other VCS users.
- liotier 3y ago
  Not just Torvalds and hosting Linux development: Git solves "big code" problems and large organizations pull the market - including tiny projects for which Git's trade-offs are not optimal, where Mercurial tended to make users happier.
- bvrmn 3y ago
  For me it was a quite important factor TBH in 2007 when I wanted to try something new outside of SVN. And it was my big argue point to force my company to switch to Git.
- flohofwoe 3y ago
  IMHO it was Github which made git popular. GH filled a gap left when Sourceforge went down the shitter, and Github was there at the right time to host open source projects for free. The actual version control system used (svn vs git) wasn't all that important. The important feature was free hosting.
fer 3y ago
Disclaimer: I haven't touched hg in nearly a decade. hg has (had?) a sane CLI that blows (blew?) git out of the water. I like the power of git, but it either needs external tooling to prevent people from shooting the team in the foot, or relatively thorough study by everyone using it. In practice, for git, most of the time you need some software to protect people from messing up repositories and history (gitlab, github, etc, which honestly you're gonna use anyway), while hg on its own protects you out of the box from most mistakes. All FAANGs I'm familiar with use git, but there are some serious handrails and straps on what you can do. On smaller companies I had so many arguments about rebasing public branches that it's not even funny. For a while I had in the back of my head to create a hg clone that was a wrapper around git, in a way that it'd allow hg-style workflows and protections, while having a faster and more well-known "backend".
- Ygg2 3y ago
  If hg cli was butt raving mad, it would still be considered "saner" than git. If git was an equivalent modern appliance, it would be against the Geneva convention. I give Git this, it's a bit faster.
  - otabdeveloper4 3y ago
    Git is not opinionated and doesn't care about your workflow, which is why it won in the end. (The downside is that, yes, it's ultimately just a collection of tools, not a "framework" for doing software.)
    - Ygg2 3y ago
      Non-opinionated is not an excuse. It's CLI is an unlearnable mess ( ours vs theirs). I've got 10 years in it and it still bites me in the ass.
      - jahav 3y ago
        Maybe, but normal developer interracts with sane parts. Honestly, the biggest problem with git is sane environment for merge conflicts and that is out of scope of git CLI. In most cases, imposing rule for small PRs/feature branches will solve it. git add, git commit, git log, git blame, git push, git rebase -i --onto. That is 95+% of what developers use (maybe an option here or there, like -m or --amend). Merges are done on CI after it passes. There are a lot of arcane parts and switches. git-send-email is likely used a lot on kernel development, but very rarely in the rest of the world. > I've got 10 years in it and it still bites me in the ass. Can you give some examples? I had some problems in the beginnings, but it was because i tried to be "smart". After I embraced KISS, everything works nicely. As long as I keep "public" branches protected, any splash zone is very small and at worst, just redo it(synergy with small PRs).
deleted 3y ago
[deleted]
woadwarrior01 3y ago
In the early days, the git UX was quite rough around the edges and Mercurial was a lot more idiot proof than git was. Git has evolved significantly since then.
joewalker 3y ago
When the decision was made to use Mercurial, Git for Windows wasn't a viable option. If you wanted to develop on Windows, the choices were Mercurial or SVN. Edit: I work for Mozilla, although I didn't in 2006 when I think the decision was made.
kbrosnan 3y ago
Git did not run on Windows when Mozilla moved. Git on Windows required running Cygwin was prone to breaking on Cygwin and was slow. This was a pretty big dealbreaker for Mozilla. The imports of Mozilla's ~10 years of CVS dev via the version control's import tool was fragile and none of them imported cleanly without patches. https://soberbuildengineer.com/blog/2007/04/version-control-system-shootout-redux-redux/index.html https://soberbuildengineer.com/blog/2007/04/version-control-... https://soberbuildengineer.com/blog/2006/11/version-control-system-shootout-redux/index.html https://soberbuildengineer.com/blog/2006/11/version-control-...

Is there a reason why they used Mercurial as opposed to git? Did it provide some benefit?

by mgd 3y ago

Is there a reason why they used Mercurial as opposed to git? Did it provide some benefit?

vardump 3y ago

Probably tooling and developer mindshare. Might not have much to do with git vs Mercurial technical merits.

zilti 3y ago
"developer mindshare" has become one of the most bullshit reasons to use something.
- j1elo 3y ago
  "developer mindshare" usually equals better or at least more support. Which is not at all a bullshit reason to use something.
- sshine 3y ago
  For that reason alone, yes. But not for the reasons that correlate, such as education, tooling.
Espressosaurus 3y ago
Yeah. From a technical standpoint Git is a lot worse in a lot of ways. From an ease-of-use standpoint it's about as much worse as it's possible to be. Still, with Linux behind it, Git won the DVCS wars. Mercurial became an also-ran and now almost nobody uses it. Too bad. We'll need something new and innovative to come out and rid us of constant blogs explaining how Git works because it's too hard to understand how to make it do the things you want it to do. I've been using Git for about 7 years now (5 exclusively) and I know how to use it, but I still have to look things up occasionally because its UI is trash and non-obvious. I didn't have that problem with Mercurial. There, I knew the verb and the built-in help was sufficient to get me where I wanted to go. Worse is better wins again.
- TerrifiedMouse 3y ago
  > We'll need something new and innovative to come out and rid us of constant blogs explaining how Git works because it's too hard to understand how to make it do the things you want it to do. Read about Jujutsu awhile back. https://news.ycombinator.com/item?id=30398662 https://news.ycombinator.com/item?id=30398662
- pptr 3y ago
  I really enjoy the simplicity of Googles internal repo (piper). I am quite surprised that no open source variant has been created yet (that I'm aware of).
  - Ygg2 3y ago
    How does piper work?
- WesolyKubeczek 3y ago
  > Yeah. From a technical standpoint Git is a lot worse in a lot of ways. From an ease-of-use standpoint it's about as much worse as it's possible to be. Ten years ago, when I had started to use git after having used both Subversion and Mercurial, I noticed one thing. Git was FAST. On repositories of the same size, git was blowing Mercurial out of the water and running circles around it, that's how fast it was. It was FAST and it fucking got out of my way and let me work. I don't know the inner workings of either and academic advantages of Mercurial, but I know for a fact it had been a dog and its move to Python 3 had been disastrous. So whichever technical or UX advantages Mercurial might have, I simply don't care anymore.
  - geraldwhen 3y ago
    Younguns may forget or never have experienced branching an svn repo. It used to literally take hours. Then git-svn was born, and you could branch instantly. This was such an obvious improvement that all future repos moved to git.
    - 3y ago

hiddencost 3y ago

https://wiki.mozilla.org/VersionControlSummit2006 https://wiki.mozilla.org/VersionControlSummit2006

dale_glass 3y ago

Mercurial came out about a week after Git did. I've not used it in a long time but I recall that it was a lot less confusing than Git to use. But Git definitely won the war, and Mercurial has been disappearing little by little.

gtsteve 3y ago

The two came out at roughly the same time and for the first few years it wasn't really obvious which was better. Personally, I chose Mercurial to start with, because I liked the Windows tooling available and it felt a lot more like Subversion, which is what I used previously. However, Git won the mindshare war in the end, so I moved over to that.

santiagobasulto 3y ago
Happened the SAME thing to me. Mercurial felt more natural than git. Back then, Github allowed you to choose the VC and Mercurial and Git were available, I'd always choose Mercurial. I was also using Google Code that allowed for mercurial as well. Ahhhh, thanks for brining back those memories.
- antod 3y ago
  > Github allowed you to choose the VC and Mercurial and Git were available You're not thinking about BitBucket are you? I thought Github was always git only?
  - pseudalopex 3y ago
    GitHub started with Git and added Subversion. Never Mercurial.
    - antod 3y ago
      Oh that's right - I'd forgotten about that april fools joke that wasn't. It was just client compatibility right - the backend was still git from memory? What I mean was that it wasn't like Bitbucket where you chose whether you wanted git or hg for starting your project.
      - innocenat 3y ago
        BitBucket was Mercurial-only for quite some times before they added Git (when it was obvious that Git was winning). I think Google Code provide both from the early day (along with Subversion), and maybe also SourceForge.

deleted 3y ago

[deleted]

bsder 3y ago

Yeah, the mental model of Mercurial is way better. Unfortunately, GitHub got VC funding and caused network effects to kick in. Git came along with GitHub as a parasite much like C came along as a parasite with Unix.

adastra22 3y ago
I'm a huge critic of git, but I think it won out on merits. Git was used by the Linux kernel, and therefore from the beginning scaled better to much larger projects than other DVCS systems.
- Ygg2 3y ago
  Except it doesn't scale to codebases the size of Facebook and Google.
  - jahav 3y ago
    MS stores windows codebase in a single repo (https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/ https://devblogs.microsoft.com/bharry/the-largest-git-repo-o...). 300GB. I don't really see a benefit of having all code of an org in a single repo. Single product, sure. But whole company? Why. Not to mention, these are serious outliers. From security standpoint, it doesn't seem great, from practical side, it's not great (bandwidth cost ect).
    - Ygg2 3y ago
      There was similar push by Facebook to improve Mercurial perf and they showed some impressive advantage over Git. It seems it was abandoned eventually for Git.
  - dig1 3y ago
    > Except it doesn't scale to codebases the size of Facebook and Google. Actually, it scales well with large codebases, but the monorepo mental model pushed by FB/Google doesn't match the git workflow model. Git repo design is for a concrete entity: a single tool, binary, service, kernel, whatever. When you start bashing in multiple unrelated projects where you try to have various per-project versioning schemas, it becomes a mess.

Xenoamorphous 3y ago

I wonder how much the “victory” of git vs mercurial was influenced by having a big name like Linus Torvalds behind it.

VMG 3y ago
big name and big speed - I distinctly remember how slow "mercurial" was when git started dominating
- ygra 3y ago
  Since then both had lots of optimizations put into it to work outside their original intended domains. Facebook did a lot to make Mercurial performance on very large repositories tenable. Microsoft did the same for Git to allow their Windows developers to work with Git, which apparently was initially not able to do common operations at all at acceptable speed. But those are big company problems and I suspect the caveats, tradeoffs and solutions matter a lot less for the 99 % of other VCS users.
liotier 3y ago
Not just Torvalds and hosting Linux development: Git solves "big code" problems and large organizations pull the market - including tiny projects for which Git's trade-offs are not optimal, where Mercurial tended to make users happier.
bvrmn 3y ago
For me it was a quite important factor TBH in 2007 when I wanted to try something new outside of SVN. And it was my big argue point to force my company to switch to Git.
flohofwoe 3y ago
IMHO it was Github which made git popular. GH filled a gap left when Sourceforge went down the shitter, and Github was there at the right time to host open source projects for free. The actual version control system used (svn vs git) wasn't all that important. The important feature was free hosting.

fer 3y ago

Disclaimer: I haven't touched hg in nearly a decade. hg has (had?) a sane CLI that blows (blew?) git out of the water. I like the power of git, but it either needs external tooling to prevent people from shooting the team in the foot, or relatively thorough study by everyone using it. In practice, for git, most of the time you need some software to protect people from messing up repositories and history (gitlab, github, etc, which honestly you're gonna use anyway), while hg on its own protects you out of the box from most mistakes. All FAANGs I'm familiar with use git, but there are some serious handrails and straps on what you can do. On smaller companies I had so many arguments about rebasing public branches that it's not even funny. For a while I had in the back of my head to create a hg clone that was a wrapper around git, in a way that it'd allow hg-style workflows and protections, while having a faster and more well-known "backend".

Ygg2 3y ago
If hg cli was butt raving mad, it would still be considered "saner" than git. If git was an equivalent modern appliance, it would be against the Geneva convention. I give Git this, it's a bit faster.
- otabdeveloper4 3y ago
  Git is not opinionated and doesn't care about your workflow, which is why it won in the end. (The downside is that, yes, it's ultimately just a collection of tools, not a "framework" for doing software.)
  - Ygg2 3y ago
    Non-opinionated is not an excuse. It's CLI is an unlearnable mess ( ours vs theirs). I've got 10 years in it and it still bites me in the ass.
    - jahav 3y ago
      Maybe, but normal developer interracts with sane parts. Honestly, the biggest problem with git is sane environment for merge conflicts and that is out of scope of git CLI. In most cases, imposing rule for small PRs/feature branches will solve it. git add, git commit, git log, git blame, git push, git rebase -i --onto. That is 95+% of what developers use (maybe an option here or there, like -m or --amend). Merges are done on CI after it passes. There are a lot of arcane parts and switches. git-send-email is likely used a lot on kernel development, but very rarely in the rest of the world. > I've got 10 years in it and it still bites me in the ass. Can you give some examples? I had some problems in the beginnings, but it was because i tried to be "smart". After I embraced KISS, everything works nicely. As long as I keep "public" branches protected, any splash zone is very small and at worst, just redo it(synergy with small PRs).

deleted 3y ago

[deleted]

woadwarrior01 3y ago

In the early days, the git UX was quite rough around the edges and Mercurial was a lot more idiot proof than git was. Git has evolved significantly since then.

joewalker 3y ago

When the decision was made to use Mercurial, Git for Windows wasn't a viable option. If you wanted to develop on Windows, the choices were Mercurial or SVN. Edit: I work for Mozilla, although I didn't in 2006 when I think the decision was made.

kbrosnan 3y ago

Git did not run on Windows when Mozilla moved. Git on Windows required running Cygwin was prone to breaking on Cygwin and was slow. This was a pretty big dealbreaker for Mozilla. The imports of Mozilla's ~10 years of CVS dev via the version control's import tool was fragile and none of them imported cleanly without patches. https://soberbuildengineer.com/blog/2007/04/version-control-system-shootout-redux-redux/index.html https://soberbuildengineer.com/blog/2007/04/version-control-... https://soberbuildengineer.com/blog/2006/11/version-control-system-shootout-redux/index.html https://soberbuildengineer.com/blog/2006/11/version-control-...