Earlier quoted context omitted.
> Mercurial is over. I mean to be fair so is Firefox
Wait until Google starts to suppress ad blockers for real in a few months.
People will switch to brave, not Firefox.
I kind of killed Mercurial at Mozilla
121–130 of 250 posts
Re: I kind of killed Mercurial at Mozilla
#122Earlier quoted context omitted.
`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.
This sounds reasonable but I'd like to somehow distinguish these work-on-progress commits. Is there an equivalent of mercurial commit phases?
Like the parent said, you typically let the "automatic working copy commit" take the place of the staging area. Really, the staging area still exists in some sense, but it's not a distinct "thing" in the UX; rather than being represented by a unique name in the tool's lexicon (the "index"), it's just represented by another commit. So, you slice and dice that commit, as you see fit.
Similarly, there is no concept of stash. The working-copy-commit model removes the need for a distinct "stash" verb, just like it removes the need for the "index" noun.
(In Git, stashes and the staging area are of course trees of blobs, just like ordinary commits. It's just that the UI surfaces them as distinct nouns.)
> This sounds reasonable but I'd like to somehow distinguish these work-on-progress commits. Is there an equivalent of mercurial commit phases?
There isn't any current notion of phases right now, but we've thought of adding them. At the moment, the main distinction added recently is between "immutable" commits and mutable ones, which is determined by a revset, and that revset by default is something like "Anything published on or an ancestor of a head in the remote." Immutable commits cannot be rewritten to a new commit ID.
Frankly I just tag all of my work-in-progress commits with 'wip:', and I use a revset to select and look through every change authored by me that isn't located in the remote main branch.
We are also thinking about improving the color and iconography of the default output to make immutable vs mutable more distinct. So we're not sure if we even need phases yet, I think...
Re: I kind of killed Mercurial at Mozilla
#123I 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…
I can't speak for those other people, but as someone who likes MQ (even today!) I think one advantage is its conceptual simplicity. It's literally just patch files; you can edit them by hand if desired. For people comfortable with or used to that, I can see the allure vs. the more mysterious operations occurring in "rebase --interactive" and such. Even quilt, the MQ progenitor, is still used today (at least on Debian).
Wasn't there an option (4): using 'qsave' and 'qpush --merge' to merge two MQ series with 3-way merge support? I don't think I've every really used it, though.
But overall, yeah Mercurial was playing catch-up to Git on that front for a while. Surely didn't help adoption.
Re: I kind of killed Mercurial at Mozilla
#124Earlier quoted context omitted.
> It's just the network effect It's almost like qwerty vs dvorak in that regard, except git and mercurial were contemporaries. Mercurial isn't quite good enough to displace git, and git has Linus as a promoter which was all it needed to be the leader. That said, I agree that the network effect of having just one is more valuable than mercurial's ergonomics (which could still use a good branch story).
Mercurial also missed the window on performance and safety. If you started using it around 2009 or so, Hg was notably slower for daily use and a lot of people recommended using extensions to match Git features but those extensions were not stable (Hg and RCS are the only VCSes I’ve seen require data to be recovered from a backup due to normal usage). There’s a meme that Git is hard to use but I think it’s conflating…
> There’s a meme that Git is hard to use but I think it’s conflating the challenges of getting used to version control at all, distributed version control, and any specific tool
That may be the case for some people, but far from all. Many people who started with cvs or even rcs and have moved on to the newer things as they have appeared still find got annoying and unintuitive. Especially compared to Mercurial.
You use it, because it is now the standard, but you are also very aware of how much cleaner and easier other systems have been.
Re: I kind of killed Mercurial at Mozilla
#125I'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.
Bias warning: I created CodeApprove to give GitHub reviews a better UI.
GitHub PR review UI is … fine. But it has very little depth. Unlike an IDE it’s hard to grow into a power user of it. It seems to be optimized for simple reviews with 1-2 rounds of a few comments each.
When you do dozens of code reviews every week you want something more. You want something snappy and dense with keyboard shortcuts. You want something that draws your attention to where it’s needed and something that helps you ensure all your conversations reach resolution.
So there’s a lot of room for improvement and GitHub hasn’t shown much interest in improving this area. So 3p UIs are stepping in (Graphite, CodeApprove, Reviewable, etc)
Re: I kind of killed Mercurial at Mozilla
#126Earlier 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.
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)
Re: I kind of killed Mercurial at Mozilla
#127Earlier quoted context omitted.
Because you never wrote it. The curse of open source. By the time github came about, git already had a lot more mindshare than hg. While hg wasn't yet clearly an also ran, it was clearly the less popular solution, and many open source tools started supporting git but either not supporting hg, or if they did it was an afterthought and often the maintainers broke something hg without noticing and then releasing with br…
maybe. at least on windows TortoiseHg was far superior to TortoiseGit. just to be clear, i have worked with both hg and git, and can get along with either, but i do prefer hg. have also written several foss tools - for example csvfix.
Don't get me wrong, there were lots of great hg tools. However the majority of tools were for git and so the few better ones for hg don't make up.
Re: I kind of killed Mercurial at Mozilla
#128Earlier quoted context omitted.
That change was so dumb. Mercurial support was the bit that put them as something different from github. Once they didn't have it anymore, why would anyone use them at all?
One huge advantage for them compared to GitHub is that they offer an on-prem version. That is much more relevant than Hg support of all things. It also gets bundled with Jira and Confluence.
GitHub has GitHub Enterprise Server?
Re: I kind of killed Mercurial at Mozilla
#129Re: I kind of killed Mercurial at Mozilla
#130Interesting, given that Google and Facebook [2], at least, eventually moved to have their repositories offered via Mercurial interface, instead of git. I also would expect that Github eventually will also offer mercurial repos. p.s. And let's not talk about abomination that is GitLFS (starting from the fact that it requires separate subcommand). [2] https://engineering.fb.com/2014/01/07/core-infra/scaling-mer...
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.