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

91–100 of 250 posts

Re: I kind of killed Mercurial at Mozilla

#91

Post by cmrdporcupine »

aseipp wrote: post #69
danking00 wrote: post #23

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…

Yes, this, but you've made a very long and amazing and intricate description of something that basically amounts to an essential workflow thing that those of us who worked at e.g. Google or on Chromium just found intuitive and normal: the comments I make are on the specific code/diff at the point in time that the comment was made and when I see you've resolved or updated it, I as a reviewer can see exactly what changed.

GitHub's PR tool sucks for this. It's also clunky, wastes boatloads of screen real estate, and lacks keyboard shortcuts.

These days I work in GitLab's MR system, and it's meh, but slightly better. But I still miss Gerritt. So much better, even if takes a while to get used to.

Re: I kind of killed Mercurial at Mozilla

#92

Post by [deleted] »

steveklabnik wrote: post #25
danking00 wrote: post #23

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 know people who express similar feelings. Usually it is shorthand for "I would prefer stacked diffs" or similar. Two blog posts I've seen people point at: * https://mitchellh.com/writing/github-changesets * https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/

[deleted]

Re: I kind of killed Mercurial at Mozilla

#93

Post by KerrAvon »

whoateallthepy wrote: post #28
danking00 wrote: post #23

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 point: if you are re-reviewing, other platforms (e.g. Phabricator, Gerrit) have much more developed ways to compare changes relative to one another.

Phabricator was awful. It loaded commit messages with irrelevant boilerplate and allowed people to post patches that you couldn’t build for testing because they were just diffs and not actual branches in the repo. Not sad to see it go.

Re: I kind of killed Mercurial at Mozilla

#94

Post by KerrAvon »

lima wrote: post #63
zoogeny wrote: 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…

GitHub PRs are both bad process (no stacking or per-commit review, incentivizes large changes, ...) and bad tool (no inter-diffs, noisy diffs, comments disappear through rebases, slow, ...).

> slow

but have you tried bitbucket? Omfg is it slow

Re: I kind of killed Mercurial at Mozilla

#95

Post by aseipp »

cmrdporcupine wrote: post #91
aseipp wrote: post #69

Earlier quoted context omitted.

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…

Yes, this, but you've made a very long and amazing and intricate description of something that basically amounts to an essential workflow thing that those of us who worked at e.g. Google or on Chromium just found intuitive and normal: the comments I make are on the specific code/diff at the point in time that the comment was made and when I see you've resolved or updated it, I as a reviewer can see exactly what chang…

Yes, it's long-winded, and unfortunately, it's really hard to get across with the above description that the workflow described therein actually is quite simple with the correct tools, and (at least in my opinion) also results in a technically superior outcome. Everything I described above is very intuitive and easy once you get into the groove with something like Phab or Gerrit.

Unfortunately, I think it's sort of lost on people today, because basically everyone is so stubborn about GitHub and you basically have to drag them kicking and screaming to most other tools, even if they have clearly superior UX, much less fundamental design. I used to run an open-source project and we used Phabricator and most of the regular contributors ended up liking it, but the initial hurdle for people was often like pulling teeth (and it felt like people who didn't contribute because of it never missed an opportunity to tell you so, though that may just be sour grapes on my part from hearing it so often.)

Re: I kind of killed Mercurial at Mozilla

#96

Post by [deleted] »

zoogeny wrote: post #50
danking00 wrote: post #23

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…

[deleted]

Re: I kind of killed Mercurial at Mozilla

#97

Post by cmrdporcupine »

aseipp wrote: post #95
cmrdporcupine wrote: post #91

Earlier quoted context omitted.

Yes, this, but you've made a very long and amazing and intricate description of something that basically amounts to an essential workflow thing that those of us who worked at e.g. Google or on Chromium just found intuitive and normal: the comments I make are on the specific code/diff at the point in time that the comment was made and when I see you've resolved or updated it, I as a reviewer can see exactly what chang…

Yes, it's long-winded, and unfortunately, it's really hard to get across with the above description that the workflow described therein actually is quite simple with the correct tools, and (at least in my opinion) also results in a technically superior outcome. Everything I described above is very intuitive and easy once you get into the groove with something like Phab or Gerrit. Unfortunately, I think it's sort of l…

Absolutely GitHub is so mediocre. It's fine for most open source project workflows, but when I worked for a company that used it as their main tool I was blown away how badly it managed professional-level code reviews.

Gerrit isn't beautiful, and it also had a lot of knobs that could be tweaked in weird ways. But I do miss aspects of it.

I have been wanting to check out JetBrain's code review tool and see how it looks.

Re: I kind of killed Mercurial at Mozilla

#98

Post by dehrmann »

billllll wrote: post #20
galkk wrote: post #2

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

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

Re: I kind of killed Mercurial at Mozilla

#99

Post by lmm »

Blackthorn wrote: post #13
lutoma wrote: post #4

Earlier quoted context omitted.

> I also would expect that Github eventually will also offer mercurial repos. How come? That seems highly unlikely to me, especially when you consider that one of their larger competitors (Bitbucket) had Mercurial support for a long time and then removed it.

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?

They still have a much better PR/review workflow than github. (Imagine github if reviewing showed changes since your last review by default, and it worked, and you didn't have to make junk comments to get something to count as a review, and comments didn't get lost).

Re: I kind of killed Mercurial at Mozilla

#100

Post by marwis »

aseipp wrote: post #74
culi wrote: post #59

Earlier quoted context omitted.

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

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?

Post reply on HN