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

91–100 of 263 posts

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

#91

Post by BeetleB »

locknitpicker wrote: post #28
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 also did this. Both in hindsight and at the time, I thought Mercurial had far better tooling. I recall checking Mercurial back in the day and being puzzled by the lack of basic features such as the ability to stash changes. I also recalled that the community was dismissive of the lack of such a basic feature, with comments such as users could always create local branches, of even we could perhaps install a module…

> I recall checking Mercurial back in the day and being puzzled by the lack of basic features such as the ability to stash changes. I also recalled that the community was dismissive of the lack of such a basic feature, with comments such as users could always create local branches,

I started with Mercurial, eventually got forced into git, and now use jujutsu.

Totally agree with the Mercurial developers: Just use a branch/bookmark. When I encountered it in git, it seemed neat, but became yet another concept/thing to clean up that you don't need to.

And lo and behold, after switching to jujutsu, everyone shows how you can do a stash using an (anonymous) branch.

Even though I used stash a lot in my git days, I don't miss it at all while using jujutsu. The benefit of jj is the ease with which one makes branches (without needing to name them). That's why you may not have liked the advice in mercurial - it wasn't the solution that was problematic, but that mercurial didn't make it as easy as it should have been.

(Same goes for index - no one misses it once they switch to jujutsu).

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

#93

Post by BeetleB »

I always preferred Mercurial to Git, but now that Jujutsu is out there, I think Mercurial's demise is all but guaranteed.

If there were a reliable way to use Mercurial on a Git repository, it could live. But why bother when one can use Jujutsu?

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

#94

Post by sampo »

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…

> 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 learn how it works internally.

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

#95

Post by andrewshadura »

loeg wrote: post #75
mk12 wrote: post #73

Earlier quoted context omitted.

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.

There was no headache. The migration was extremely smooth.

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

#96

Post by JoshTriplett »

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…

> Its ergonomics were superior to Git's

That's a matter of taste. I used both for serious work, at the time, and found Git much more usable. My experience with Mercurial was "welcome to Mercurial, how can we help you merge and push your work in progress even though that's not what you want?" My experience with Git was one where I felt in control at all times, had a clear workflow for when I did and didn't want to publish my changes (and for when I wanted to edit them first), and allowed me to quickly make and switch branches within a single working copy.

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

#97

Post by Xirdus »

dijit wrote: post #62
loeg wrote: 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).

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…

> Starting with C was great for performance of Git

Isn't the entire git rebase logic written in Bash scripts? Or was originally?

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

#98

Post by holoduke »

Just a bit off topic. But is anyone still using git or whatever versioning in the traditional way? I hardly see myself using the git command these days. Everything I handled by Claude. From pulling to pushing to solve merge conflicts and more. In a way it doesn't matter anymore whether it's git or something else.

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

#100

Post by fooker »

t43562 wrote: post #74
loeg wrote: 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 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 ev…

The dangerous parts of git exist to make it trivial to undo mistakes. You don’t have to use those for your regular workflows.

With any other system, your only option is usually checking out a fresh copy from a server or backup.

Post reply on HN