7 ms·

Mercurial covers generally the same concepts as git and is thus also not trivial to learn for someone uninitiated; yet its interface was like day vs. night when

by akavel 4y ago

Mercurial covers generally the same concepts as git and is thus also not trivial to learn for someone uninitiated; yet its interface was like day vs. night when compared to git since their very early days. It proves one can design a decent interface if one actually tries to care about usability and friendliness. How I remember the past days, git won the rivalry squarely due to GitHub becoming popular (though I assume there were some reasons why GH chose git over hg).

mumblemumble 4y ago
Back in the day there were actually 2 or 3 different cloud SCM hosting providers that chose Mercurial. As I recall, a couple of them, BitBucket and Kiln, also had better Web UIs than GitHub did. Versus just GitHub offering Git, and it was kind of a duffer in my opinion. GitHub has come a long way. But I would guess the main reason it managed to become dominant is not because it had a better product. (At the time, it didn't.) It's because Git benefited from the celebrity of its author, Linus Torvalds.
- theamk 4y ago
  It's crazy how people forget the past. Back in the day, git was "rewrite, rebases modify past to make beautiful commit" vs hg "rewriting past is bad, beautiful commits are lies about history". Turns out people don't care about truthful history. (Nowadays mercurial can do rebase/amend just fine.. But it is too late)
  - mumblemumble 4y ago
    I think that the truth is probably somewhere in between. I do like to squash and rebase before moving changes upstream. But, to me, that isn't really history quite yet. Or at least, it's not history that's worth recording. All those micro-commits from the work in progress are, in some ways, more akin to my editor's undo history. Which is also something I don't save. It's also clear, in hindsight, that Mercurial's original position on this subject failed to anticipate AWS credentials accidentally being committed to source control. But I have also seen (and done) some amount of history rewriting in long-lived branches that I don't think would have been necessary if Git had had some of Mercurial's ergonomics. Workflows for merging two different repositories while retaining the commit history from each, for example.
    - capitainenemo 4y ago
      FWIW, Mercurial has had "censor" command for blowing away the contents of those revisions with AWS keys since 2015. Although once stuff is pushed to the public repo you're probably going to want to change those keys regardless. And if it's on the local one, there's plenty of options for removing the commit.
  - astrange 4y ago
    Rewriting history is actively good because it means you can view it as a series of logical patches. I have worked on large projects using earlier versions of hg and they were absolutely full of merge commits just labeled "Merge" - some of them were safe, some of them had random changes in them, and some of them had automatic merged changes that actually caused problems. It was also much slower than git. But I knew someone working on Google Code at the time who liked it better because it was "clean" and in Python.
    - capitainenemo 4y ago
      It was much much faster than git at HTTP at the time though. That's why Google Code selected it. Also it was faster at imports which was why Mozilla selected it for their transition. Some other things it was slower, that's changed over time ofc. Also, in terms of clean history, mercurial has best of both worlds with phases and hidden by default commits to keep track of such cleanup.
      - astrange 4y ago
        > Also, in terms of clean history, mercurial has best of both worlds with phases and hidden by default commits to keep track of such cleanup. Yeah, it has more features now but at the time it didn’t. There was something called patch queue you could use for early stage work but that was all.
  - tessierashpool 4y ago
    in other words, the comment you’re replying to rewrote the past of rewriting the past.
  - thayne 4y ago
    The fact that mercurial is substantially slower than git was probably also a big factor.
- Izkata 4y ago
  Around 2013, having only knowledge of svn at the time, I tried both git and mercurial to see which I liked more and found git to be a lot more intuitive than mercurial. It's been long enough I don't remember the details about why I didn't like mercurial, but fame power had nothing to do with it, nor did website integration - I was only using it locally. How it worked just didn't fit with how I thought about version control.
cycomanic 4y ago
That's not what I remember. Back in the days when people started implementing dvcs git was just much faster than everyone else (that was in fact the reason why Linus wrote it). Once the kernel was using it, its mindshare just grew much faster because of the publicity this implied. In other words it was largely a case of "if the kernel devs are using it it must be good". When GitHub and all the other hosting services started many still had mercurial or other dvcs (launchpad was bzr for example), but by that time the ship had sailed already I would argue.

by akavel 4y ago

mumblemumble 4y ago

Back in the day there were actually 2 or 3 different cloud SCM hosting providers that chose Mercurial. As I recall, a couple of them, BitBucket and Kiln, also had better Web UIs than GitHub did. Versus just GitHub offering Git, and it was kind of a duffer in my opinion. GitHub has come a long way. But I would guess the main reason it managed to become dominant is not because it had a better product. (At the time, it didn't.) It's because Git benefited from the celebrity of its author, Linus Torvalds.

theamk 4y ago
It's crazy how people forget the past. Back in the day, git was "rewrite, rebases modify past to make beautiful commit" vs hg "rewriting past is bad, beautiful commits are lies about history". Turns out people don't care about truthful history. (Nowadays mercurial can do rebase/amend just fine.. But it is too late)
- mumblemumble 4y ago
  I think that the truth is probably somewhere in between. I do like to squash and rebase before moving changes upstream. But, to me, that isn't really history quite yet. Or at least, it's not history that's worth recording. All those micro-commits from the work in progress are, in some ways, more akin to my editor's undo history. Which is also something I don't save. It's also clear, in hindsight, that Mercurial's original position on this subject failed to anticipate AWS credentials accidentally being committed to source control. But I have also seen (and done) some amount of history rewriting in long-lived branches that I don't think would have been necessary if Git had had some of Mercurial's ergonomics. Workflows for merging two different repositories while retaining the commit history from each, for example.
  - capitainenemo 4y ago
    FWIW, Mercurial has had "censor" command for blowing away the contents of those revisions with AWS keys since 2015. Although once stuff is pushed to the public repo you're probably going to want to change those keys regardless. And if it's on the local one, there's plenty of options for removing the commit.
- astrange 4y ago
  Rewriting history is actively good because it means you can view it as a series of logical patches. I have worked on large projects using earlier versions of hg and they were absolutely full of merge commits just labeled "Merge" - some of them were safe, some of them had random changes in them, and some of them had automatic merged changes that actually caused problems. It was also much slower than git. But I knew someone working on Google Code at the time who liked it better because it was "clean" and in Python.
  - capitainenemo 4y ago
    It was much much faster than git at HTTP at the time though. That's why Google Code selected it. Also it was faster at imports which was why Mozilla selected it for their transition. Some other things it was slower, that's changed over time ofc. Also, in terms of clean history, mercurial has best of both worlds with phases and hidden by default commits to keep track of such cleanup.
    - astrange 4y ago
      > Also, in terms of clean history, mercurial has best of both worlds with phases and hidden by default commits to keep track of such cleanup. Yeah, it has more features now but at the time it didn’t. There was something called patch queue you could use for early stage work but that was all.
- tessierashpool 4y ago
  in other words, the comment you’re replying to rewrote the past of rewriting the past.
- thayne 4y ago
  The fact that mercurial is substantially slower than git was probably also a big factor.
Izkata 4y ago
Around 2013, having only knowledge of svn at the time, I tried both git and mercurial to see which I liked more and found git to be a lot more intuitive than mercurial. It's been long enough I don't remember the details about why I didn't like mercurial, but fame power had nothing to do with it, nor did website integration - I was only using it locally. How it worked just didn't fit with how I thought about version control.

cycomanic 4y ago

That's not what I remember. Back in the days when people started implementing dvcs git was just much faster than everyone else (that was in fact the reason why Linus wrote it). Once the kernel was using it, its mindshare just grew much faster because of the publicity this implied. In other words it was largely a case of "if the kernel devs are using it it must be good". When GitHub and all the other hosting services started many still had mercurial or other dvcs (launchpad was bzr for example), but by that time the ship had sailed already I would argue.