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

251–260 of 263 posts

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

#251

Post by MattJ100 »

harshreality wrote: post #226
MattJ100 wrote: post #206

Earlier quoted context omitted.

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

When there's an expectation or requirement that each commit builds (and even passes tests), how can you do partial commits? Do you work exclusively on projects without such requirements? Do you rely solely on CI to ensure that your commit compiles? Do you not use CI and not care if a commit is broken... you'll squash a fix in later, or not even squash it and leave a broken commit in the repo?

Each commit should build and pass tests, yes. When I say "partial commits", I don't mean that the commits are arbitrary - each commit should be as small as possible to implement a specific fix/feature. I've also heard it described as the smallest unit that you may want to revert.

For example, if you are working on something, but it requires adding an API to some module, then the first commit 1 is to add the new API (+ tests), and the second commit is the new code that uses that API.

Unfortunately many developers I have worked with would just combine these (and more) into a single commit (because they are part of the same work task). However this makes review, bisect, blame and revert harder (if you need to revert commit 2, you don't want to also revert the API you added if that was tested and bug-free).

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

#252

Post by jjav »

Arainach wrote: post #78
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).

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…

> The Mercurial CLI has clear, well named commands that are predictable and easy to memorize.

Precisely this. I've been stuck using git since 2010 and to this day I have a large git-cheatsheet doc which I need to reference any time I need to do anything beyond the daily add+commit+push. The git commands make zero sense and are just about impossible to remember because they make no sense.

In contrast, I've never felt a need for a cheatsheet doc for mercurial commands.

> done rm -rf to start anew. Every single git user I've talked to has done that multiple times.

Indeed! Of all the source control tools I've used, git is the only one where I regulary need to do a tarball of the src repo before doing any uncommon operations because there is a non-zero chance it'll go into some unrecoverable state and need to start over.

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

#253

Post by fragmede »

Ferret7446 wrote: post #180
fragmede wrote: post #168

Earlier quoted context omitted.

> Am I the exception? Supposedly, Meta has the data to support the claim that you (and I) are the outliers here. Staging is confusing to users, especially new ones, which is why jujitsu explicitly doesn't have staging.

The reason jujutsu doesn't have staging is that staging is incompatible with concurrency. The UX is a happy coincidence.

In discussions with people who made jj, it deliberately does not have Git’s staging area / index as a core concept because that was confusing for users.

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

#254

Post by irishcoffee »

pitkali wrote: post #218
irishcoffee wrote: post #148

I should write a whole article about this. Hg is a superior tool compared to git. It logically just clicks, for everyone. Changesets, branching, merging, tagging, it all just works. Git is this arcane blob of whatever-you-call-it where rewriting/erasing history is not only allowed, its encouraged. That is insane to me. Git is a fine tool, it is in every possible way inferior to hg.

I never got the idea from git itself that changing history is encouraged. What makes you say otherwise?

git rebase

Is a widely accepted command as a daily part of a development workflow. This command rewrites history.

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

#255

Post by kccqzy »

jdiff wrote: post #157
kccqzy wrote: post #104

Earlier quoted context omitted.

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

Have you used Jujutsu before? It's git-backed and it sounds like it incorporates a lot of these niceties from Mercurial. I find it an awful lot more intuitive than Git to use and the stable identifiers are absolutely lovely to have.

Of course I use jj every day. In fact it improves on mercurial by eliminating the need to run `hg evolve` because it just auto-evolves for you.

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

#256

Post by thfuran »

ciupicri wrote: post #238
thfuran wrote: post #113

Earlier quoted context omitted.

Mercurial does let you amend commits like git does, histedit is essentially identical to rebase -i, and evolve is better than anything git has.

Isn't histedit [1] an extension? I don't think it was available back then, or if I tried I didn't like it. I don't remember evolve [2] at all. [1]: https://repo.mercurial-scm.org/hg/help/histedit [2]: https://repo.mercurial-scm.org/hello/help/evolve

I’m pretty sure everything that edits history is an extension in mercurial, so both of those as well as strip and rebase.

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

#257

Post by locknitpicker »

voidnap wrote: post #37
marcher wrote: post #34

Earlier quoted context omitted.

It did have a kind of equivalent to stashes in the mq extension, but its interface was a bit esoteric compared to the rest of Hg, from what I remember.

A lot of features that git had by default had to be enabled as plugins in mercurial. The plugins were usually shipped with mercurial so you didn't have to install them separately, but you needed to know that you had to enable them in a config. And I beleive this turned a lot of people off. I think some of the extensions were very basic stuff like graph logging and colorized output -- and mq like you said. So it was k…

> The plugins were usually shipped with mercurial so you didn't have to install them separately, but you needed to know that you had to enable them in a config. And I beleive this turned a lot of people off.

It goes a little deeper than that. Prospective Mercurial users who wanted a specific feature were first greeted with claims that they were in the wrong for even entertaining the idea they needed such a thing. The rationale was that Mercurial already did everything they could possibly wanted to do, and so by definition wanting to do something differently was proof the user was in the wrong.

But to stop hearing about how feature X or Y was needed, they could roll out their own extension and leave the project alone and not bother them with these silly things.

Shipping extensions by default is an absurdity, once you think about it. It's effectively a way to disable features by default and stop hearing about how the project needs to support a feature. And that's how Mercurial dealt with it's potential user base.

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

#258

Post by Mashimo »

kccqzy wrote: post #241
Mashimo wrote: post #200

Earlier quoted context omitted.

Is that a common usecase? I think the way I would do it, is to go to target branch, cherry pick the commits and push. Then go to source branch and revert the changes. All done from within the IDE. Not the cleanest way, though.

Incredibly common when you write code faster than your colleague or manager can review them. You always have lots of branches and sometimes the branches implement interrelated functionality.

Interesting. Why not keep on a merge branch before review?

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

#259

Post by jdiff »

kccqzy wrote: post #255
jdiff wrote: post #157

Earlier quoted context omitted.

Have you used Jujutsu before? It's git-backed and it sounds like it incorporates a lot of these niceties from Mercurial. I find it an awful lot more intuitive than Git to use and the stable identifiers are absolutely lovely to have.

Of course I use jj every day. In fact it improves on mercurial by eliminating the need to run `hg evolve` because it just auto-evolves for you.

I've never had much contact with Mercurial myself, so are there any features from Mercurial that JJ doesn't already incorporate? Or any differences you find interesting?

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

#260

Post by Arainach »

loeg wrote: post #189
Arainach wrote: post #172

Earlier quoted context omitted.

git rebase -i drops you into a text editor where you have to manually copy, move, and edit lines, knowing what words mean what and manually type them each time. hg histedit gives you a TUI which shows an interactive list and allows quick manipulation with the arrow keys and single characters for actions. The two are as "equivalent" as i3 and KDE.

I don't know what version of hg you're using, but the histedit I've used drops me into an identical text editing setup as git rebase -i. It includes a summary of what the verbs mean in a comment at the bottom.

Interesting. The curses interface for histedit has been around since 2019, and I had no idea it wasn't the default since it's dramatically nicer to work with: https://www.mercurial-scm.org/relnotes/4.9
Post reply on HN