Live data from Hacker News

I kind of killed Mercurial at Mozilla

glandium.org

131–140 of 250 posts

Re: I kind of killed Mercurial at Mozilla

#131
post #42

My only experience with Mercurial was in game development. What’s used these days in arenas where large file versioning is needed? I think the ultimate answer is maintaining an asset stack containing files that allow for inherit diff chunks or however that might be described.

Yeah, my understanding is that it's pretty universally Perforce in game dev. For them it's the large file versioning. I work at an ASIC firm and we similarly use Perforce; to some extent for the large file versioning, and to some extent for other general scale benefits.

Re: I kind of killed Mercurial at Mozilla

#132

Earlier quoted context omitted.

So since you are knowledgeable about the fact that this decision was "dumb", you must also know approximately what proportion of their users were dependent on hg for their workflow ? My priors would put it at less - likely far less - than 1%. But please share your knowledge.

FWIW I had stuff on Bitbucket from the Before Atlassian times, in Hg repos. And while I had let it bitrot a bit (too complicated to work on open source stuff with my employer at the time), once they dropped Mercurial support I saw no point in moving it to git and keeping it there so I just pulled it off and move it to github. I'm sure I'm not the only one. The compelling story about Bitbucket for me was Mercurial. Pl…

> Plus Atlassian is kind of just an awful company.

How so?

Re: I kind of killed Mercurial at Mozilla

#133
post #108

I don't understand why so many people seem to dislike git. But maybe in actuality it is not many people, as usually people who are discontent are the loudest. I used Mercurial in the past for a bit, and it was fine. But for me it doesn't seem to have any huge advantages over git, if any. And after so many years of experience using git, I know what workflows work well, how to resolve merge conflicts, how to revert to…

Essentially, the problem with git is - it is a tool that is simple in its internals, but with a complex/confusing UI. The only way for someone to feel somewhat in comfortable with git is to have a good conceptual model for how it works internally. Once you have that mental model, you feel like a magician with git, but for beginners, it is a source of endless confusion and fear.

Re: I kind of killed Mercurial at Mozilla

#134
post #78

I liked the thorough article, but my goodness did they beat around the bush w/regard to their actual contribution to this process (per the title). I think the short version is: they made `git-cinnabar`, which is a git-to-hg translator, to help git users interact with the Mozilla repos. ---- One contribution I can make: > For reasons I don't know, Mozilla decided to use separate Mercurial repositories as "branches". O…

> Originally, separate clones was the recommended way to do "topic branches" in Mercurial This is still what the Guide on the Mercurial site mentions as the "basic workflow" for working on separate features. Named branches are considered "advanced", and bookmarks are an afterthought entirely. About 10 years ago, after reading a lot about how hg was more intuitive than git, I decided to give it a try. I was already us…

People like to say that github is the reason git won the dvcs wars 10 years ago, but I think this is it. I think a lot of people's first impression of git back in the day was making a local mirror of their company's svn using git-svn. Without local branches this was a pointless exercise but with git you still got some benefit even without the remote being a git repository.

Re: I kind of killed Mercurial at Mozilla

#135

Earlier quoted context omitted.

One issue I was discussing with a colleague just the other day is that you cannot leave a comment on lines that are not "part of the diff" (changed or context), which is sometimes really useful for "see this thing over here".

You definitely can comment on lines that haven't been changed. I don't think there's a way to comment on files that haven't been changed, though.

As the other commenter pointed out, only if they're close enough to a changed line. That's what I meant by "context" (borrowing terminology from diff, where you change the amount of it with -C).

Re: I kind of killed Mercurial at Mozilla

#136
post #130
post #5

Earlier quoted context omitted.

FB/Meta replaced Mercurial with Sapling which is git-compatible: https://engineering.fb.com/2022/11/15/open-source/sapling-so... Mercurial is over.

The day-to-day workflow at Meta is still using the hg frontend and regular hg commands. I would love to see the git frontend used instead, but, it hasn't happened yet.

I've switched over to using `sl` commands. Sapling is installed on ODs by default. Main change I had to get used to was `up(date)` became `goto`.

Re: I kind of killed Mercurial at Mozilla

#137

Earlier quoted context omitted.

You definitely can comment on lines that haven't been changed. I don't think there's a way to comment on files that haven't been changed, though.

Actually you can’t comment on lines that haven’t been changed if they’re too far from the changed lines! It’s a weird limitation of GitHubs data model. (source: that’s one of the features that people like most about the review tool I created, CodeApprove)

Annotations can be added by "checks" anywhere, though, I believe.

I like to use that to surface cross-references (annotating anchors whose references appear in changed or context lines, and references whose anchors do).

Re: I kind of killed Mercurial at Mozilla

#138
post #130

Earlier quoted context omitted.

The day-to-day workflow at Meta is still using the hg frontend and regular hg commands. I would love to see the git frontend used instead, but, it hasn't happened yet.

I've switched over to using `sl` commands. Sapling is installed on ODs by default. Main change I had to get used to was `up(date)` became `goto`.

I don't want to learn a 3rd thing that isn't git!

Re: I kind of killed Mercurial at Mozilla

#139
As someone who was using darcs in that era: it wasn't just slow in the sense of "it takes 10 seconds rather than 1". It was possible to get into situations where it would take hours to merge changes.

Apart from that it was the best developer experience I've had with a VCS.

Re: I kind of killed Mercurial at Mozilla

#140
I hate to see more and more people switching from Mercurial to Git. The way to overcome the "network effects" is exactly for large projects like Mozilla to stand tall and say clearly that they are going to use Mercurial because it is better and git is worse.

Of course, I shouldn't really expect such from Mozilla given all the other dubious actions they've taken over time.

Post reply on HN