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

51–60 of 263 posts

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

#51

Post by ncphillips »

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’ve recently switched to jj and it is truly amazing. It too about a week for me to “get it”. The tool is amazing but I think there’s way too much emphasis on what it does/allows rather than what benefits it brings to your workflow. If they get that marketing right I could see it growing. If not, I’ll keep using it

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

#52

Post by jjav »

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.

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

#53

Post by fHr »

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…

meanwhile my org still uses svn for a lot of repos at least my teams are full git...ugh

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

#54

Post by ahartmetz »

juvoly wrote: post #21
tasuki wrote: post #17

Earlier quoted context omitted.

> Mercurial wasn't as simple as Subversion. What? Subversion is by far the most complex versioning software I've ever used. > Git has so many gotchas, bells and whistles The Git UI leaves a little to be desired. But inside, Git is basically just blobs, trees, commits, and refs. It'd be hard (or impossible?) to find a conceptually simpler versioning system.

You're right about SVN's guts vs Git. I should have been clearer that I was referring to the client cli only.

Just an example that I recently noticed when I briefly had to use svn again:

Show a diff: svn diff / git diff

Show log with diffs: svn log --diff / git log --patch

Git calling the same or similar things different (or just terrible - tree-ish? ref?) names is one of the worst things about Git.

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

#55

Post by somewhatgoated »

amluto wrote: post #24
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 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)

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

#56

Post by loeg »

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.

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

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

#57

Post by dragochat »

MBCook wrote: post #43
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.

Agreed. For a complicated long running feature branch I can see it. Instead of repeatedly merging the root in during development it can be cleaner. Tools aren’t always good at figuring out in a PR what was written and what was caused by those merges from root. And history looks better at the end. For a short branch that can merge cleanly or perhaps very close to it, I’d kind of rather have the ‘true’ history. I don’t…

exactly the opposite:

"For a complicated long running feature branch" always simpler to repeatedly merge main into dev, easier conflicts solving etc

For simpler cases squash+rebase as default merge strategy trumps leaves a nice clean history.

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

#58

Post by loeg »

avarun wrote: post #15
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…

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.

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

#59

Post by loeg »

Shish2k wrote: post #30
ssttoo wrote: post #23

IIRC Facebook switched to HG from SVN in the 2010s, one (main?) motivator being that the single repo was getting too big and svn’s only way was to start splitting it up. Which was against the philosophy of openness of the single repo. No idea what’s Meta doing now.

Last I checked (2 years ago) Meta was using Sapling, a very heavily customised open source Mercurial frontend with proprietary backend. FWIW the Sapling frontend can also be connected to a Git backend, and I've been using that for all my open source projects to get the best of Mercurial's user experience niceness while collaborating via GitHub <3

Still Sapling + Eden to make local work on a sparse checkout viable.

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

#60

Post by martin-t »

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 hate that social factors like popularity are a thing in technical decisions.

I have not used mercurial (though heard good things about it) but I saw a similar thing play out in Rust gamedev. There are 2 competing game engines, one better technically, the other much more popular. Now, if everyone made a purely technical decision, they'd pick the first one and eventually it would become the more popular one. Unfortunately, whenever I asked people why they chose the second one, they said because it was more popular. Tragedy of the commons.

If it's any consolation, maybe jj will take over. I haven't tried it yet (I use the staging area a lot in my workflow), but AFAIK they made the choice to be git-compatible which means it's not a choice between one or the other but lets people and teams migrate gradually.

Post reply on HN