Live data from Hacker News

Mercurial, 20 years and counting: how are we still alive and kicking? [video]

fosdem.org

111–120 of 263 posts

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#111
post #52

Earlier quoted context omitted.

Mercurial is one of the many sad stories of far better technology being forgotten by the popularity contest juggernaut of something else. I still use mercurial for all my personal project where I don't need to care what anyone else thinks. It is pleasant to use good tools, just like I like to buy top quality rachets or such.

Can't comment on Mercurial, but "for all my personal project where I don't need to care what anyone else thinks" I am using Fossil. Ever since that decision, I've felt a bit, well, held back, or rather, I don't feel quite as comfortable as I do at home when I have to use Git.

I've always been interested in Fossil, especially how they handle all the things in a project that aren't strictly code but still need to be tracked.

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#112
post #102
post #56

Earlier quoted context omitted.

Mercurial wasn't the better technology, though. The UX is almost the same as git, diverging in ways that are arguably worse, but the tools were written in much slower Python (initially, and for many years after).

I’ve never met a single person who can use git to move a commit and its descendants from one parent to another. This requires using the extremely unintuitive `git rebase --onto A B C` invocation. The only exception are magit users who are dealing with a much better interface and a better name (magit calls it rebase subset rather than onto). In contrast every single mercurial user I know can intuitively use `hg rebase…

You need to say “ i’ve never met anyone who could do that in one single command line invocation”. It’s trivial to separate that result into two or more steps using bare primitive git commands and perhaps a temporary branch. You don’t need to memorize every esoteric flag if you understand the fundamentals and don’t mind spending 15 extra seconds to execute multiple commands

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#113
post #66

Earlier quoted context omitted.

> I helped them make the wrong choice, Mercurial. 20 years ago, Mercurial was not the wrong choice. - Its internal design was very similar to Git's. - Its cross-platform support was superior to Git's. (Git didn't get good Windows support until some years later.) - Its ergonomics were superior to Git's, which was an important factor on its own, and especially important when trying to get a whole organization to retrai…

I don't know what you mean by ergonomics, but I remember trying both Mercurial and Git back in the days after using Subversion before. I didn't like how Mercurial didn't easily let me rewrite history and do stuff like `git commit --ammend` or `git rebase`. Mercurial users kept telling me using an extension to manage patches on top of Mercurial (I think it was quilt). I agree about the Windows support. hg serve was al…

Mercurial does let you amend commits like git does, histedit is essentially identical to rebase -i, and evolve is better than anything git has.

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#114
post #87
post #56

Earlier quoted context omitted.

Mercurial wasn't the better technology, though. The UX is almost the same as git, diverging in ways that are arguably worse, but the tools were written in much slower Python (initially, and for many years after).

> The UX is almost the same as git, I've used git and mercurial for roughly the same amount of time. Your statement is, frankly, something that makes me question your sanity. They're not remotely similar. Outside of something like Perforce, I've not used a VCS with a worse UI.

[deleted]

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#115
We used Mercurial at reddit. We switched to it shortly after switching to Python as our main language, figuring it would be easier to use the one written in Python.

We used Mercurial until the day we went open source. We actually preferred it, but we knew at that point that "everyone" used Git, and we would never be seen as serious or get user contributions unless we switched. That was back in 2008. [0]

We actually self hosted a ticketing system[1] and our own git repo, but since the system we used didn't have pull requests, we had to use the old school method of sending us a patch via mailing list using the git-send-email command, the same way the linux kernel did it.

The best part of this is that we had a launch party for open sourcing in San Francisco. The date of the party was chosen a few months in advance, because it takes that long to plan something in physical meat space. This was basically the first time reddit ever had a hard deadline to get something done.

I was primarily responsible for setting up the ticketing system and code repo, and at the same time, we were switching our actual servers to pull from our public code repo for deployment, for true transparency (and I had to set all that up too).

I actually had to do the final setup to make everything public sitting at the bar at the venue with my laptop about five minutes before we opened the doors. At the time, I had about a week of experience with git! And here I was, operating what was expected to be a very popular open repo that anyone could clone from. Good times.

[0] https://web.archive.org/web/20080619043654/http://blog.reddi...

[1] https://web.archive.org/web/20080622134154/http://code.reddi...

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#116
post #87
post #56

Earlier quoted context omitted.

Mercurial wasn't the better technology, though. The UX is almost the same as git, diverging in ways that are arguably worse, but the tools were written in much slower Python (initially, and for many years after).

> The UX is almost the same as git, I've used git and mercurial for roughly the same amount of time. Your statement is, frankly, something that makes me question your sanity. They're not remotely similar. Outside of something like Perforce, I've not used a VCS with a worse UI.

I’ve used both in parallel for 10 years or so. They are very similar, I find no problem switching back and forth

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#117
post #58
post #15

Earlier quoted context omitted.

Around 20 years ago Facebook made the same choice, so you're in good company in terms of technically sophisticated shops.

Facebook has been using their own in-house Sapling/Eden for years and years now. I'm not sure how much similarity remains with open source Mercurial.

You can use all the normal hg commands at Meta. It’s a regular mercurial repo from the standpoint of a user

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#118
post #15

Almost 20 years ago I helped our company choose between Git and Mercurial as the replacement for Subversion. Unfortunately, I helped them make the wrong choice, Mercurial. I say wrong because clearly Git won the war and I haven't used Mercurial since then. However, I still think I made the right choice from a technical perspective; I thought Mercurial was way more user-friendly while providing all the features and pe…

Around 20 years ago Facebook made the same choice, so you're in good company in terms of technically sophisticated shops.

Facebook didn’t adopt mercurial until something like 2014? And before that used svn -> git

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#119
post #94

Almost 20 years ago I helped our company choose between Git and Mercurial as the replacement for Subversion. Unfortunately, I helped them make the wrong choice, Mercurial. I say wrong because clearly Git won the war and I haven't used Mercurial since then. However, I still think I made the right choice from a technical perspective; I thought Mercurial was way more user-friendly while providing all the features and pe…

> But I guess I couldn't read the future in terms of which one would win out! After Linus Torvalds gave this talk at Google in 2007, it was clear he would win. (Is there a better quality video somewhere?) https://www.youtube.com/watch?v=idLyobOhtO4 But I agree: Mercurial was definitely friendlier for people who didn't have time time to go through the technicalities of git. To use git smoothly you pretty much need to…

To be entirely fair nothing in git backend prevents someone to make friendlier frontend.

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#120
post #102

Earlier quoted context omitted.

I’ve never met a single person who can use git to move a commit and its descendants from one parent to another. This requires using the extremely unintuitive `git rebase --onto A B C` invocation. The only exception are magit users who are dealing with a much better interface and a better name (magit calls it rebase subset rather than onto). In contrast every single mercurial user I know can intuitively use `hg rebase…

You need to say “ i’ve never met anyone who could do that in one single command line invocation”. It’s trivial to separate that result into two or more steps using bare primitive git commands and perhaps a temporary branch. You don’t need to memorize every esoteric flag if you understand the fundamentals and don’t mind spending 15 extra seconds to execute multiple commands

Okay so the same operation with git is an esoteric flag but it’s easy in mercurial. Got it. Which has the better UX then?

> It’s trivial to separate that result into two or more steps

Okay first, tell me how to separate it into two or more steps. Second, tell me why a single operation in a user’s mental model needs to be split into two commands. The user is thinking about moving a commit and its descendants from one place to another; why should this seemingly atomic operation be split.

Post reply on HN