Live data from Hacker News

I kind of killed Mercurial at Mozilla

glandium.org

141–150 of 250 posts

Re: I kind of killed Mercurial at Mozilla

#141
post #69

I've heard this point of view many times, but cannot find an extensive explanation of it. Could anyone elaborate on the issue with the GitHub review UI/UX? > I hate the GitHub review UI with a passion. At least, right now, GitHub PRs are not a viable option for Mozilla [...] the more general shortcomings in the review UI.

Most of the projects that dislike GitHub's review UI want the functional equivalent of `git range-diff`. Code review systems like Phabricator and Gerrit basically revolve around this as basis of thinking about diffs, their evolution, and how code review progresses. You want to write 3 patches to a project, that are committed in series, based off of `X` A ---> B ---> C X---/ Let's say A cleans up some code, getting it…

This is an incredible workflow as someone who has only ever used git and GitHub (and poorly at that).

I presume there isn’t really any way to have this kind of workflow using git and GitHub? I’d be interested in something like this at my company but we’re sorta locked in to GitHub already.

Re: I kind of killed Mercurial at Mozilla

#142

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.

Git won a long long time ago. Most people’s first VCS is now git. Mercurial is a lot better than SVN so it was able to pick up users back when SVN was dominant, but it’s not really better or worse than git it’s just down to taste. When you consider the network effects and switching costs it’s hard to convince anyone that mercurial is worth learning.

Re: I kind of killed Mercurial at Mozilla

#144
What a shame.

I came in contact with version control systems in the following order CVS (also a bit of a weird episode using RCS), Subversion, git, then mercurial

I have loved git and still do. But nowadays I use mercurial for my pet projects.

There is no denying that git "won", mercurial would have been a worthy alternative.

Re: I kind of killed Mercurial at Mozilla

#145
post #50

Earlier quoted context omitted.

I once worked with a guy who hated Python. He also hated IntelliJ and did all of his programming in Eclipse. He hated MacOS and would only run old versions of Windows of Linux. What I found was that he was just sensitive to change. It took him awhile to get comfortable with something but as soon as he did he would from then on resist any change. Anything that was different to what he was used to he hated . In some se…

> Anything that was different to what he was used to he hated. I suspect he just hated the constant churn. That's kind of a rational frame of mind when you think about it.

I enjoy learning new things, but my bar for "is this actually better?" seems to be unconsciously higher than it used to be.

Re: I kind of killed Mercurial at Mozilla

#146
post #59
post #54

Earlier quoted context omitted.

Google currently uses a fork of Mercurial as the frontend to Piper, but there is work to replace it wholesale, eventually: https://github.com/martinvonz/jj (As a disclosure, I'm involved with and contribute to jj, but I don't work for or speak for Google in any way; the above statement is public knowledge.)

Any comments about what it does better than git and mercurial?

Personally, I like the elimination of staging and stashing. These always seemed like unnecessarily separate concepts.

But what I'm most interested in exploring is support for first-class conflicts. I hate the weird state of existing git conflict resolution.

Re: I kind of killed Mercurial at Mozilla

#147
post #134
post #78

Earlier quoted context omitted.

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

Back in the day I was doing some GCC development while upstream was still using SVN. At that time there was both Hg and Git mirrors, and while the GCC repo isn't that huge in the grand scheme of things, it's big enough that the "standard" hg workflow of having a separate checked out tree for every local branch you're working on was definitely painful. While I had been using hg for some personal projects, this was really the killer feature that drove me to git.

Re: I kind of killed Mercurial at Mozilla

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

Aside from the terrible UI that several other people have mentioned, there are some other things that Git does badly (though I don't know if Mercurial does better):

* Large projects. It has poor monorepo support (especially on Linux), and also poor multirepos support (submodules are really buggy).

* Large files. LFS is a PoC-level hack; not a proper solution.

* Conflict resolution. The default diff algorithm is very dumb, and even with `zdiff3` it doesn't quite give you enough information to easily resolve all conflicts.

Re: I kind of killed Mercurial at Mozilla

#150

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…

One of the biggest problems with Mercurial is that they took a long time for histedit to become a usable workflow. I speculate (without any evidence, so this could be entirely wrong) that this is because many Mercurial contributors preferred MQ over editing history for local patches. (Certainly I knew many Gecko developers who swore by MQ.) Coming from Git, with the git rebase --interactive flow coupled with the refl…

MQ was a big revelation after working for 3 years with Git. Until I faced with StGit, it was much easier to use and fill more native especially with rebases.
Post reply on HN