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

121–130 of 263 posts

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

#121

Post by atq2119 »

ern wrote: post #36
rileymat2 wrote: post #33

Earlier quoted context omitted.

I think I liked the Mercurial branching model better than git, due to the branches being a first class record of events. What I did not know is how common the git rebase/clean linear history would become or a desire to change history on merge. Mercurial had bookmarks that were roughly the same as git branches. The linear version numbers were quite useful to reason about and use in places that call for a "number" vers…

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.

It really depends on how often you use git bisect and blame. This varies greatly across projects.

That said, if/when stacked PRs become a first-class citizen in GitHub, more projects will see the benefit of this approach (though they'll probably mostly get there through squash-merges).

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

#122

Post by 12_throw_away »

KwanEsq wrote: post #4
macro-b wrote: post #3

At my previous big tech employer we used to have a mercurial layer on top of our legacy version control system. I loved it, much simpler and more clear than the typical workflows I have to deal with in git. I get it that with git you have more power, but do really most teams need that?

Do you actually even have more power with git?

Unless git has some hidden way to do changeset evolution (maybe with jujutsu on top?) then no - I'm pretty sure git is strictly less powerful than hg these days.

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

#124

Post by pif »

esafak wrote: post #89
3form wrote: post #31

Earlier quoted context omitted.

I'm glad that I stuck to git for a similar reason; it won the war. And I understand the need for simpler tools. But to offer a point I haven't heard from anyone before: at least I feel that I am done with it, I learned this tool sufficiently and I can move on with my life. From time to time I add something to my git toolbelt. I feel if Mercurial or anything else have won, I would maybe have to learn another tool in 5…

Despite not using anything else, I don't know all the git commands I need to get my job done so I use UIs and my agent. It's just not intuitive enough, some things are just not possible to do right, and I look forward to ditching it.

> some things are just not possible to do right

If git doesn't let you do them "right", your concept if "right" is wrong.

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

#125

Post by [deleted] »

ahartmetz wrote: post #54
juvoly wrote: post #21

Earlier quoted context omitted.

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.

[deleted]

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

#126

Post by streetfighter64 »

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 Git CLI requires you to understand its internal data structures to understand the difference between a rebase and a merge, and most people still can't explain it.

I don't know anything about mercurial, but is it really too much to ask of software engineers to understand a DAG (the only "internal data structure" in question)?

About rm -rf ing a repo, I'm sure if mercurial was more popular it would also suffer from the types of coders that would do such things on a regular basis.

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

#127

Post by loeg »

zeroonetwothree wrote: post #117
loeg wrote: post #58

Earlier quoted context omitted.

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.

You can use all the normal hg commands at Meta. It’s a regular mercurial repo from the standpoint of a user

Yeah, but people using open source mercurial aren't in the same boat. It's a different codebase.

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

#128

Post by throw-the-towel »

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.

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?

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

#130

Post by nezi »

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.

Is git really far worse technology than mercurial? I’ve used both for years and to be honest they are pretty similar. What important capabilities does hg have that git does not? Maybe you can argue that hg is more ergonomic, but that’s just polish it doesn’t mean the tech is far better…
Post reply on HN