Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

fosdem.org

Post reply on HN
Print view View original

71–80 of 263 posts

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

#71

Post by blagie »

somewhatgoated wrote: post #55
amluto wrote: post #24

Earlier quoted context omitted.

I also did this. Both in hindsight and at the time, I thought Mercurial had far better tooling. But it was not all amazing: Mercurial’s branching model was very poor, and its sequentially numbered revision system was and remains a very bad design.

I always hear it has far better “tooling” but then the comments say that branching sucks, revisions suck and there is no good got stash equivalent - this is like a third of what I use daily with git. What does “far better tooling” mean exactly, could you give an example of what amazing tools I’m missing out on (never have used anything else but git, when I came to the industry it was already the standard)

When I used it a decade ago, virtually everything in mercurial was slightly better-designed, more user-friendly, and more polished. Much shorter learning curve.

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

#72

Post by [deleted] »

IshKebab wrote: post #64
dijit wrote: post #62

Earlier quoted context omitted.

Writing your tooling in python is valid while starting out and prototyping. One of the big criticisms I've seen levied against Rust is that refactoring is extremely difficult, so prototyping on ideas in the language itself is a poor experience. I've personally had great success using python, then gradually rewriting the tool I have with py03 to "oxidise" the program iteratively. Starting with C was great for performa…

> Writing your tooling in python is valid while starting out and prototyping. This fallacy again. Tell me, when did Mercurial decide "ok the prototype is done, we'll rewrite it in a proper language"? They didn't, of course. Because nobody ever does. Your "prototype" gradually becomes a 100k line product that you can't afford to rewrite. (I guess you can YOLO it with AI these days but that wasn't an option for Mercuri…

[deleted]

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

#73

Post by mk12 »

IshKebab wrote: post #64
dijit wrote: post #62

Earlier quoted context omitted.

Writing your tooling in python is valid while starting out and prototyping. One of the big criticisms I've seen levied against Rust is that refactoring is extremely difficult, so prototyping on ideas in the language itself is a poor experience. I've personally had great success using python, then gradually rewriting the tool I have with py03 to "oxidise" the program iteratively. Starting with C was great for performa…

> Writing your tooling in python is valid while starting out and prototyping. This fallacy again. Tell me, when did Mercurial decide "ok the prototype is done, we'll rewrite it in a proper language"? They didn't, of course. Because nobody ever does. Your "prototype" gradually becomes a 100k line product that you can't afford to rewrite. (I guess you can YOLO it with AI these days but that wasn't an option for Mercuri…

The Mercurial project has been incrementally rewriting core operations in Rust for several years now. As Pierre-Yves says in the talk, you can do an hg status on a million-file repo in 100ms. I rewrote hg annotate (aka blame) in Rust last year.

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

#74

Post by t43562 »

loeg wrote: post #56
jjav wrote: 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.

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 thought it was enormously better because it helped you not to cut yourself with all the dangerous things in a way that git didn't. It also had an excellent GUI (thg).

It was a much less stressful tool to use and git hasn't really got much better since then - I've just converted a repo to git and the team using it have had about 4 unpleasant mistakes in the last week as they adapt.

As for speed.....I cannot say I ever noticed any problem. Waiting around for the version control system has never been an issue for me.......except a git repo with 70,000 commits and we worked out how to merge a lot of those to fix the problem.

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

#75

Post by loeg »

mk12 wrote: post #73
IshKebab wrote: post #64

Earlier quoted context omitted.

> Writing your tooling in python is valid while starting out and prototyping. This fallacy again. Tell me, when did Mercurial decide "ok the prototype is done, we'll rewrite it in a proper language"? They didn't, of course. Because nobody ever does. Your "prototype" gradually becomes a 100k line product that you can't afford to rewrite. (I guess you can YOLO it with AI these days but that wasn't an option for Mercuri…

The Mercurial project has been incrementally rewriting core operations in Rust for several years now. As Pierre-Yves says in the talk, you can do an hg status on a million-file repo in 100ms. I rewrote hg annotate (aka blame) in Rust last year.

It's kind of late, though, right? Git had core components ("plumbing") in C from 2005, with gradual rewriting of the "porcelain" layer from Perl to C in the late 2000s and early 2010s. People have been complaining about Mercurial performance for a long time. I'm sure the Python 2->3 headache did not help.

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

#77

Post by ciupicri »

foresto wrote: post #66
PathOfEclipse wrote: post #10

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…

> 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 also nice. Plus TortoiseHg.

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

#78

Post by Arainach »

loeg wrote: post #56
jjav wrote: 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.

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).

How do you consider the UX "nearly identical" or "arguably worse"?

The Mercurial CLI has clear, well named commands that are predictable and easy to memorize. hg histedit is clean and easy to use and visually shows you what is going to happen - what the new order will be - nondestructively.

The Git CLI requires you to understand its internal data structures to understand the difference between a rebase and a merge, and most people still can't explain it.

I've worked with Mercurial for 5+ years and no one on my team has ever given up on a client and done rm -rf to start anew. Every single git user I've talked to has done that multiple times.

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

#79

Post by t43562 »

somewhatgoated wrote: post #55
amluto wrote: post #24

Earlier quoted context omitted.

I also did this. Both in hindsight and at the time, I thought Mercurial had far better tooling. But it was not all amazing: Mercurial’s branching model was very poor, and its sequentially numbered revision system was and remains a very bad design.

I always hear it has far better “tooling” but then the comments say that branching sucks, revisions suck and there is no good got stash equivalent - this is like a third of what I use daily with git. What does “far better tooling” mean exactly, could you give an example of what amazing tools I’m missing out on (never have used anything else but git, when I came to the industry it was already the standard)

It had a much better GUI in 2009 (THG) and I think today the GUIs for git aren't really better - probably worse.

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

#80

Post by ciupicri »

t43562 wrote: post #70

Mercurial was safer and better. I still use it and it's still safer. The bookmarks feature which is supposed to be the solution for short-lived branches is hard to understand though. I'm probably dumb but I can't work it out and hence the overall tool is that much less useful. It needs a github-like website and Heptapod would be great if I could use it - I've set up a project, been unable to do anything and then had…

I hated so much how Mercurial dealt with short-lived branches, that after seeing how Git did it, I've never looked back. I also remember how some people told me to use the quilt or something extension to manage patches, but it was too complicated for me.
Post reply on HN