Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I kind of killed Mercurial at Mozilla

glandium.org

Post reply on HN
Print view View original

111–120 of 250 posts

Re: I kind of killed Mercurial at Mozilla

#111

Post by marwis »

plorkyeran wrote: post #105
marwis wrote: post #100

Earlier quoted context omitted.

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.

This sounds reasonable but I'd like to somehow distinguish these work-on-progress commits. Is there an equivalent of mercurial commit phases?

Re: I kind of killed Mercurial at Mozilla

#112

Post by dzaima »

naasking wrote: post #101
jorams wrote: 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…

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

You don't make multiple forks of a project if you want to PR multiple separate changes though (github doesn't even allow it). And, on top of that, last I heard, forks in github are actually implemented as git branches. :)

Re: I kind of killed Mercurial at Mozilla

#113

Post by nine_k »

LAC-Tech wrote: post #8
wmf wrote: 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.

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

Re: I kind of killed Mercurial at Mozilla

#114

Post by anyonecancode »

lima wrote: post #66
anyonecancode wrote: post #51

Earlier quoted context omitted.

From the second article, a minor point but possibly helpful to other here, he contrasts doing everything in the terminal with stacked commits vs going to the Github UI. If people aren't aware, Github offers a cli tool[1]. I've been using it for a few months now and am finding it does make me more productive -- it's nice to be able to open up a PR directly from my terminal. I do still use the GH UI for a lot of things…

The CLI doesn't help with stacked commits, though. There's tools like spr[1] but none of them are anywhere as pleasant to use as Gerrit (or Phabricator, I guess). [1]: https://github.com/ejoffe/spr

It doesn't -- hence my noting the GH cli as a minor point. It's a tool I've personally found helped increase my productivity, so just wanted to share as others may find it useful too.

Re: I kind of killed Mercurial at Mozilla

#115

Post by swozey »

oktwtf wrote: 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.

I've only used SVN and Git and I'm almost 20 years into my career at this point so I know nothing of these others but my game dev friends all use Perforce. I couldn't tell you a single thing about it though.

Re: I kind of killed Mercurial at Mozilla

#116

Post by bigstrat2003 »

cmrdporcupine wrote: post #110
wsc981 wrote: 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 advantag…

Exactly this. To be perfectly honest, the git CLI is so bad that I would take pretty much anything over git. I would prefer SVN over git, despite that product being older and with less functionality, just because it's at least easy to use.

I learned and use git because that's just how the industry has moved, and I'm pragmatic enough to just roll with it. But good Lord, the UI is a case study in "programmers shouldn't be allowed to design UIs".

Re: I kind of killed Mercurial at Mozilla

#117

Post by acdha »

dehrmann wrote: post #98
billllll wrote: post #20

Earlier quoted context omitted.

Bitbucket dropped Mercurial support in 2020: https://bitbucket.org/blog/sunsetting-mercurial-support-in-b... I just don't think there is good RoI for implementing Mercurial support. It really isn't about the interface (which I think most people agree hg is better than git). It's just the network effect: most projects use git so everybody learns git and they don't want to learn another tool even if it's better in some…

> 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 the challenges of getting used to version control at all, distributed version control, and any specific tool. I watched a number of developers do that and it was about as much work to go from SVN to either Git or Mercurial, and if they learned the other DVCS it was always easier since they were mapping concepts rather than learning them for the first time. The marginal returns on productivity weren’t worth switching in most cases so it tended to come down to Git being so much faster and, as network effects kicked in, easier to host.

Re: I kind of killed Mercurial at Mozilla

#118

Post by speed_spread »

wsc981 wrote: 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…

> after so many years

This is why so many people dislike git. It's a base tool that should have an obvious workflow and very few pitfalls. Instead it allows one to do just about anything at anytime without giving much of a fuck about any resulting mess. All blade, no handle. It's a tool for Linus, by Linus. The average corporate coder is not Linus and doesn't have Linus problems. People don't want a Merkle tree manager, they want a workflow.

Re: I kind of killed Mercurial at Mozilla

#119

Post by pcwalton »

interroboink wrote: post #41

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 reflog to provide a backup to let you undo any mistakes, MQ was awful. Your choices were (1) allow hg qrefresh to overwrite the old contents of your patches and hope you never made mistakes, or (2) make your patchqueue an hg repo and have to look at second-order diffs. (I chose option (3)--symlink my patchqueue into Dropbox so that I could use Dropbox's history feature as a kind of poor man's reflog.) And to top it all off, MQ didn't understand three-way merge logic the way git rebase does. This workflow seems to me clearly worse than Git's tools, and I'll never understand why so many developers at Mozilla claimed to prefer MQ over Git.

Re: I kind of killed Mercurial at Mozilla

#120

Post by replwoacause »

speed_spread wrote: post #118
wsc981 wrote: 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…

> after so many years This is why so many people dislike git. It's a base tool that should have an obvious workflow and very few pitfalls. Instead it allows one to do just about anything at anytime without giving much of a fuck about any resulting mess. All blade, no handle. It's a tool for Linus, by Linus. The average corporate coder is not Linus and doesn't have Linus problems. People don't want a Merkle tree manag…

Exactly….

(I strongly dislike git and much prefer KISS tools)

Post reply on HN