Live data from Hacker News

I kind of killed Mercurial at Mozilla

glandium.org

101–110 of 250 posts

Re: I kind of killed Mercurial at Mozilla

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

Separate clones are basically exactly like forks on GitHub, which is pretty standard these days. Seems they were ahead of the curve (again).

Re: I kind of killed Mercurial at Mozilla

#102

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.

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.

Re: I kind of killed Mercurial at Mozilla

#103
post #34

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.

bitbucket is worse, reviewees can resolve reviewer's comments (github has this too turns out), after file changes, comments disappear

Bitbucket is much better IME. It has a better handle on the current state of the review rather than offering you the whole diff to re-review whenever someone rebases, and it loses comments much less than github (indeed not at all, in my experience).

Re: I kind of killed Mercurial at Mozilla

#104
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?

The big idea that excites me is that it does away with the concept of having uncommitted changes. Instead, every time you save a file in a repository it is automatically committed. It is the logical endpoint of the git workflow where you make lots and lots of little wip commits and then rewrite them into a sensible set of commits later, and the whole UI is designed around making that work well rather than being something that works but constantly feels like it's off the intended path.

Re: I kind of killed Mercurial at Mozilla

#105
post #100
post #74

Earlier quoted context omitted.

I completely rewrote the README recently to be more "user friendly"; does it address some of your question? I'm not trying to be snarky, I'm genuinely interested in if the README is now tantalizing enough to make you interested: https://github.com/martinvonz/jj?tab=readme-ov-file#introduc... But in short, it has a better UX than Git by a mile while remaining interoperable at the storage level, so you can use GitHub;…

Lack of staging area kind of sucks. I'd prefer the opposite - having multiple staging areas (like IntelliJ chabgelists) so I can incrementally build multiple changes at the same time. Is there anything in jj that could be used as a substitute?

`jj split` and `jj move` are the equivalent of git's staging areas. Instead of picking which changes you want to commit, you pick which changes you want to move from the working-copy commit to the target commit you're assembling. It lets you do something very similar to multiple staging areas by having multiple commits that you're moving changes to.

Re: I kind of killed Mercurial at Mozilla

#106
post #50

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.

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.

Re: I kind of killed Mercurial at Mozilla

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

> This is still what the Guide on the Mercurial site mentions as the "basic workflow" ...

I imagine you're referring to the "hg book"[1] ?

It irks me that that site hasn't been updated since ~2009, and there doesn't seem to be anything equivalent for "modern" Mercurial. Alas.

EDIT: oh, looks like there is a somewhat newer version (~2015?): https://book.mercurial-scm.org/read/part-getting-started.htm...

[1] http://hgbook.red-bean.com/

Re: I kind of killed Mercurial at Mozilla

#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 an old commit if something really gets messed up, etcetera.

I don't see any other DVCS really being able to replace git in the short run and I wouldn't be surprised if git will stay number 1 for the following decennia, as in my opinion it's really great software. A DVCS really has to provide substantial benefits over git in order to replace git as the number 1 DVCS.

Re: I kind of killed Mercurial at Mozilla

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

The sheer functionality of git is amazing. The number of times I have encountered a new situation and used a previously unknown (to me) feature, or (equally as impressive) been able to harness the flexibility of the software to wrangle some strange edge case are innumerable. All that while also being lightning fast.

Re: I kind of killed Mercurial at Mozilla

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

Git functionality is great. But the CLI just kind of grew in a nonsensical way. No serious effort seems to have been made on UX consistency and verb/noun names.

People who've been using it for years don't notice, they don't even think about it. But when coming from scratch, it's anything but intuitive. The CLI is not discoverable in a reasonable way.

That and there's so many ways to use it.

Mercurial had the advantage of having a much more consistent UX. Though these days I'm sure I'd struggle with it, because I'm so used to git.

Mercurial was never trying to "replace" git. All of these guys came out at the same time. Git got headspace because Linux used it and GitHub was a "cool" Ruby on Rails site, run by cool web 2.0 kids, same era as the rise of Twitter, etc. (And also down all the time, just like Twitter).

Post reply on HN