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

211–220 of 263 posts

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

#211

Post by pitkali »

bsder wrote: post #192
streetfighter64 wrote: post #153

Earlier quoted context omitted.

Well I can explain git to anybody who understands a DAG. And mercurial is also based on the exact same data structure. So yes it would be very surprising if you didn't consider it to be "acceptable". The fact that there's lots of training data out there on strange git states is proof of exactly my point. Git is popular and thus used by lots of people who don't know the first thing about the command line, let alone da…

> Well I can explain git to anybody who understands a DAG. This. Right here. This is the difference. I can explain Mercurial to people who don't want to understand a DAG. For non-professional developers, the "merge machinery" is completely worthless. The difference is that Mercurial lets you duck it until you need it while Git slaps you in the face with it at every commit. For the non-professional developer, the flow…

The non-professional flow you described does not require merging in git either. I suppose most teaching resources about git go deep into merging because it was created for distributed development where that's important, but it doesn't mean you have to teach it to a non-professional like that.

Not that I think mercurial didn't have "simpler" UI back then, but the arguments thrown around in this thread are pretty bollocks.

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

#212

Post by pitkali »

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 had an easier to use command line interface. If that's what makes it far better technology, we have a very different idea what makes the "technology" better.

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

#213

Post by pitkali »

rileymat2 wrote: post #33
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 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 way I remember it was that bookmarks were added because the git branching model became so popular. The "branches" in Mercurial were allegedly not designed with short-lived feature branches in mind.

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

#214

Post by pitkali »

amluto wrote: post #108
somewhatgoated wrote: post #55

Earlier quoted context omitted.

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.

Meh. While I agree that Mercurial had easier to use CLI, there was maybe 1 time over the last 15 years or whatever when I needed anything other than git reset --hard.

Although, I suppose part of this is just that manipulate index with something like lazygit.

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

#215

Post by pitkali »

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

I don't think the internal design is/was that similar. We switched from CVS to git, and were evaluating multiple choices. What tipped the scale in the end was our trust in the internal data model, which for git was the idea that it stores the snapshots, and they are immutable. The diffs you can get out of it are calculated on demand. Even if on-disk storage can end up using some diffs to save on space, the actual conceptual model of every operation is based on those snapshots, and that is also how every new commit is stored before repacking the repository.

This appealed greatly to us, and always meant that it is effortless to undo any operation because it only creates new snapshots, while the previous ones stay there for a while in case you need to recover the previous state.

This is in contrast with Mercurial, where the data store is (was?) a sequence of diffs, and then the state of the working tree at any time is reconstructed on demand from those diffs.

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

#216

Post by anal_reactor »

dwattttt wrote: post #152
anal_reactor wrote: post #135

Earlier quoted context omitted.

You mean "git tag"?

If you tag every commit, sure. You don't know which commit has a bug that needs to be fixed in advance. And at the point you're tagging every commit, you're fighting git. EDIT: reconsidering: you would have to move a tag when you make changes. A tag is just giving a name to a commit, not a stable identifier that follows a change. A branch is a more appropriate analogy. A git-native workflow for this would be to have…

When you fix bugs, you don't edit history, you treat these as new features.

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

#217

Post by dwattttt »

anal_reactor wrote: post #216
dwattttt wrote: post #152

Earlier quoted context omitted.

If you tag every commit, sure. You don't know which commit has a bug that needs to be fixed in advance. And at the point you're tagging every commit, you're fighting git. EDIT: reconsidering: you would have to move a tag when you make changes. A tag is just giving a name to a commit, not a stable identifier that follows a change. A branch is a more appropriate analogy. A git-native workflow for this would be to have…

When you fix bugs, you don't edit history, you treat these as new features.

Correct. The comparable git workflow when you fix a bug is that the work goes on the branch of the feature the bug was in, and "main" is updated to use the new head of that branch.

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

#218

Post by pitkali »

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?

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

#219

Post by spacechild1 »

qsera wrote: post #194
spacechild1 wrote: post #155

Earlier quoted context omitted.

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

People make this claim but it never made sense to me. How do you know the version that you are committing is buildable if you never tried building with it? And if you tried building with it, you can just do `git add .` or `git add -u` at that point. So yes, your usecase does not make sense to me. There was another comment that said similar thing... https://news.ycombinator.com/item?id=48175289 >So you're just constan…

1. CI

2. Why should comments or printf statements affect the build? When it compiles with them, why shouldn't it compile without them?

3. the commits might be temporary and get squashed anyway

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

#220

Post by spacechild1 »

MattJ100 wrote: post #206
spacechild1 wrote: post #155

Earlier quoted context omitted.

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

That makes sense, thanks for clarifying!
Post reply on HN