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

201–210 of 263 posts

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

#201

Post by koonsolo »

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

In Mercurial, a branch is a branch. In git, a branch is not really a branch but a pointer.

So already the naming in git is very confusing, and conceptually it clearly is very different from Mercurial because of this reason.

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

#202

Post by koonsolo »

zeroonetwothree wrote: post #116
BeetleB wrote: post #87

Earlier quoted context omitted.

> 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

I can also switch back and forth between JavaScript and C++. Doesn't mean they are similar.

Conceptually, branches in git and mercurial are worlds apart.

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

#203

Post by Seattle3503 »

Mashimo wrote: post #197
didibus wrote: post #181

Earlier quoted context omitted.

I often want to "save" but not have a comment, and not ready to make it a clean commit that I want a comment on. That's when I stage, then I can see the diff and revert still. But ya, maybe I could adapt to not worrying about having a million commits instead of clean ones at points that make sense with good comments.

You could also commit, and then squash the pull request.

Does mercurial allow you to re-write history like that?

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

#204

Post by t43562 »

fooker wrote: post #100
t43562 wrote: post #74

Earlier quoted context omitted.

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.

I upvoted because even though I prefer Mercurial I do like tools that are powerful and flexible.

The problem for me is that VCSes have a mental model and the way they actually work is more complicated than that. I haven't tried to deeply understand Git and in a way I slightly resent needing to - even Mercurial has the same problem in some areas but there it's more about a feature I want and the oddly contorted way they achieve it (specifically bookmarks) and it's not a situation where I get into danger and don't know how to get out.

Branches are great. I don't want to know that they're "just a pointer". :-D I'm so dull that I never use the "staging" concept because it's just a huge opportunity for making mistakes (for me). I really want something simple to reason about where I can add little complexities if I need them.

To take the bad Mercurial example - I don't really need permanent branches and I definitely don't need some new concept with oddly different commands to give me impermanence. Let me delete a branch!

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

#205

Post by Espressosaurus »

kccqzy wrote: post #102
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’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…

And if you don't know the syntax off the top of your head, as long as you know the verb you can find out what it is.

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

#206

Post by MattJ100 »

spacechild1 wrote: post #155
bsder wrote: post #138

Earlier quoted context omitted.

> Is git really far worse technology than mercurial? Git is far worse simply because of "staging". "Staging" may be necessary (I do not concede this) in big projects, but in small projects it's an absolute disaster to the mental model. Most people on small projects just want "checkpoint the current code in my directory and put a comment on it". In addition, Git's UX is hot garbage. I would constantly be doing rsync o…

> Most people on small projects just want "checkpoint the current code in my directory and put a comment on it". Interesting, that's definitely not how I use git. My current code is rarely in a shape that can be fully committed. It often contains additional stuff I did on the way (small bug fixes, TODO comments, debug printf statements, etc.) that I don't want in the commit. Very rarely do I type `git add .` Am I the…

To be clear, Mercurial does not have a staging area, but it does have allow selective commits (and selective uncommits) via prompt-based or interactive UI selection of hunks. Disagreeing with the need for a staging area is not the same as saying selective commits are unnecessary (I use Mercurial more than git and I rarely commit everything in my working directory in a single commit - I like small commits).

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

#207

Post by fooker »

Arainach wrote: post #143
throw-the-towel wrote: post #128

Earlier quoted context omitted.

Can any of the downvoters comment on this? My experience with Git is pretty much the same, but maybe Hg also allows you to unfuck a screwed up repo, just as Git does?

The bad states Git "allows you to unfuck" are largely caused by Git's awful UX (confusing and multipurpose commands based on inner workings), so Git gets no credit for "solving" a problem it caused.

Not just mistakes though, the power of git is being able to undo anything you do with git.

If you’re claiming to have never needed any kind of undo functionality, you probably don’t even need a version control system :)

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

#208

Post by MattJ100 »

Seattle3503 wrote: post #203
Mashimo wrote: post #197

Earlier quoted context omitted.

You could also commit, and then squash the pull request.

Does mercurial allow you to re-write history like that?

Yes, Mercurial has a very advanced history editing system via "evolution": https://wiki.mercurial-scm.org/ChangesetEvolution

A good way of thinking about it is that every commit is itself version-controlled, allowing unlimited edits. This even allows two people in an evolve-enabled repo to make changes to history at the same time, and Mercurial will resolve any conflicts. It makes it trivial to commit (and even share) a "WIP" commit which you can later amend/split/whatever. It's different from git where you basically can't edit history after pushing (in Mercurial this only becomes true if you push to a non-evolvution or "publishing" repo, where everything then gets squashed for public consumption).

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

#209

Post by 59nadir »

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.

While I agree that Mercurial probably lost a ton of users for not clearly addressing performance issues for quite a while, I've found it's never too late to switch from using git, to be honest. I am personally using Fossil for all of my projects and it's been a great experience overall. I didn't have particularly challenging needs when it came to git so I wouldn't say that it's been a major headache overall for me, but I also think Fossil just is better as a default than git for everything that I do (and everything I've ever worked on):

- Assume we want to sync to main repo as a default when issuing operations, keeping us in sync more often and easily

- `commit` just commits all indexed files with changes, no need for staging

- Worktrees by default (admittedly this is more of a convention and you can certainly do the same with `git worktree`, but it's very prominent in how they show you how to use Fossil).

- `fossil ui` for having your own mini-GitHub is great, and having changes you make there sync with your remote is incredibly convenient.

- `fossil serve` on your remote is a great way to make your mini-GitHub an actual persistent service. I've used SSH remotes for `git` but as far as setup goes this actually is a close second in terms of convenience. Nevermind setting up a more involved forge; `fossil serve` is overperforming for what you get by a lot here.

All in all switching to Fossil after a ton of time using git has been a great experience overall.

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

#210

Post by garganzol »

We support Mercurial project financially and we use it everyday. While I use Git for hobby projects, it does not cut it in terms of ease of use. Some newer SCM systems like jj look promising, but absence of tools like TortoiseHg undermines their possible adoption.
Post reply on HN