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

101–110 of 263 posts

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

#101

Post by atq2119 »

JoshTriplett wrote: post #96
foresto wrote: 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…

> 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 pub…

Thank you. I vaguely remember being put off by Mercurial at the time and feeling much more comfortable with git, but couldn't have put it into words as well as you did.

People always say you have to know git internals in order to use it, but that's just not true. Git has the right data model and has always been about empowering users to edit their data. Which makes the data model be "in your face" compared to the alternatives (and I think that's what people latch on to when they talk about "internals"), but it ultimately makes for a better tool.

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

#102

Post by kccqzy »

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’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` with its `-s` and `-d` flags. That’s one giant difference in UX.

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

#103

Post by bluGill »

BeetleB wrote: post #88
ern wrote: post #36

Earlier quoted context omitted.

The clean linear history thing is something I never really got, despite using git for 12 years now. I worked with some smart developers whose rule was "rebase if you want, but if too complicated, just merge", and it didn't hurt the delivery or maintainability of the code they wrote.

Yes - whenever I'm in a team and I hear someone who insists on a linear history, I always wonder why they have trouble with merge when lots of folks like me have no problem with it. Finally, in one team, I more or less forced a senior engineer use merge (or rather, I was in control of the project and did not force other developers to use rebase). After a year, he admitted that he no longer really saw a benefit in reb…

Rebase makes sense when you realize git doesn't have branches. Git has tags that move but no branches. That means when you merge you have no clue which branch was the mainline and which was the fork. This is a question I often ask 10 years after switching to git. Sadly git has better tooling so it is worth using despite the issues.

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

#104

Post by kccqzy »

loeg wrote: post #82
Arainach wrote: post #78

Earlier quoted context omitted.

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, a…

> How do you consider the UX "nearly identical" or "arguably worse"? The core concept is similar -- history is a stream of content-addressed commits. Concepts map almost 1:1. git does some things arguably better. > hg histedit is clean and easy to use and visually shows you what is going to happen - what the new order will be - nondestructively. hg histedit is basically identical to git rebase -i. The names are diffe…

> history is a stream of content-addressed commits

Not quite true for mercurial. You also get stable identifiers for commits that remain the same even after being manipulated such as after rebases or amends. It also enables tracking the evolution of a changeset which then enables `hg evolve`.

Being content addressable isn’t a desirable feature in a user-friendly version control system. Who cares about it? Giving stable identifiers to commits is a much more needed feature.

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

#105

Post by justin66 »

BeetleB wrote: post #87
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).

> 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 not used a VCS with a worse UI

...than git? than hg?

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

#107

Post by kccqzy »

BeetleB wrote: post #93

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?

Jujutsu took the best parts about mercurial and enabled these to be used with git and git forges. Once I had gotten used to jujutsu I didn’t really miss mercurial.

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

#108

Post by amluto »

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)

“Far better tooling” means that you don’t need to do git help reset and try to remember each of the nonsensical choices, for example.

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

#109

Post by lmm »

yegle wrote: post #47
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 have the feeling that Git winning the war hinges heavily on GitHub being the way to do open source projects, and that is changing given the sad state of GitHub. Another contender is Jujutsu (jj) which allows you to use jj as frontend and use Git as the backend (with the potential to support any backend, e.g. Google's proprietary Piper), with the best ergonomic and the widest availability of hosting solutions.

> I have the feeling that Git winning the war hinges heavily on GitHub being the way to do open source projects

Nah. At the time BitBucket was the better way to do open source projects, and they were Mercurial-first. But eventually they had to add Git support because there was so much demand.

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

#110

Post by F3nd0 »

jjav wrote: post #52
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…

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.

And in a similar vein, Darcs. It unfortunately couldn’t compete with Git on performance, but the user experience is on a whole another level.
Post reply on HN