Comment by adamwk

> I'm so glad git won the dvcs war. There was a solid decade where mercurial kept promoting itself as "faster than git".

It wasn't the Mercurial team saying it was faster than Git; that was Facebook after contributing a bunch of patches after testing Mercurial on their very large mono-repo in 2014 [1]:

For our repository, enabling Watchman integration has made Mercurial’s status command more than 5x faster than Git’s status command. Other commands that look for changed files–like diff, update, and commit—also became faster.

In fact they liked Mercurial so much they essentially cloned it to create their own dvcs, Sapling [2]. (An aside: Facebook did all of this because it was taking too long getting new engineers up to speed with Git. Shocker.)

Today, most of the core of Mercurial has been rewritten in Rust; when Facebook did their testing, Mercurial was nearly 100% Python. That's where the "Mercurial is slow" thing came from; launching a large Python 2.x app took a while back in the day.

I was messing with an old Mercurial repo recently… it was like a breath of fresh air. If I can push to GitHub using Mercurial… sign me up.

[1]: https://engineering.fb.com/2014/01/07/core-infra/scaling-mer...

[2]: https://sapling-scm.com/

What is kind of funny here is that you're right locally. At the same time, the larger tech companies (Meta and Google, specifically) ended up building off of hg and not git because (at the time, especially) git cannot scale up to their use cases. So while the git CLI was super fast, and the hg CLI was slow, "performance" means more than just CLI speed.

I was never a fan of hg either, but now I can use jj, and get some of those benefits without actually using it directly.

I remember using darcs, but the repos I was using it with were so small as to performance really not mattering…

This matches my experience 100%. I was about to write a similar comment before I see yours.

I just used it because I preferred the UX.

Mercurial has a strictly superior API. The issue is solely that OG Mercurial was written in Python.

Git is super mid. It’s a shame that Git and GitHub are so dominant that VCS tooling has stagnated. It could be so so so much better!

Git is not remotely fast for large projects.

Most editors have some kind of way to review github PRs in your editor. VSCode has a great one. I use octo.nvim since I use neovim.

Same team, and a rare hill I'm willing to die on.

Rant incoming...

Boy do I hate Github/Lab/Bucket style code reviews with a burning passion. Who the hell loses code review history? A record of the very thing that made my code better? The "why" of it all, that I am guaranteed to forget tomorrow morning.

Nobody would be using `--force` or `--force-with-lease` as a normal part of development workflow, of their own volition, if they had read that part of the git-push manpage and been horrified (as one should be).

The magit key sequence for this abominable operation is `P "f-u"`. And every single time I am forced to do it, I read "f-u" as it ought to be read.

Rebase-push is the way to do it (patch sets in Gerrit).

Rebase-force-push is absolutely not.

You see, any development workflow inevitably has to integrate changes from at least one other branch (typically latest develop or master), without destroying change history, nor review history. Gerrit makes this trivial.

It's a bit difficult to convey exactly why I'm so rah-rah Gerrit, because it is a matter of day-to-day experience of

  - Well, a single commit of a few lines to maybe a hundred lines *is* the correct unit of code review, rebase, revert etc. Manually "Sizing PRs" to that review context size is utter BS. I have better things to do in life than to book-keep PR sizes. Make a single well-contained, revertible commit. Then keep making those. And now you have a commit history that is clean, that you can merge, bisect, and bulk-revert at will. Octopus merges are a good thing. `git-log` is *designed* to let us view changes in any sequence we wish, *including* the so-called "linear" history. `git log --online`.

  - Trivial for committer to send up reviews-preserving rebase-push responses to commit reviews (NO force-push, ever --- that's an "admin" action to *evict* / permanently wipe out disaster scenarios such as when someone accidentally commits and pushes out a plaintext secret or a giant blob of the executable of the source code etc.).

  - Fast-for-the-reviewer, per-commit, diff-based, inline-commenting code reviews.

  - The years-apart experience of being able to dig into any part of one's (immutable) software change history to offer a teaching moment to someone new to the team.

... to name a few key ones.

(edit: add point about review size)

Same here. Don't understand why Github hasn't supported this until now. I'm tired of reviewing PRs with thousands of lines of changes, which are getting worse nowadays with vibe coding.

What does Facebook use internally these days. I'm amazed that the state of review tools is still at or behind what we had a decade ago for the most part.

Me too. And I'm speaking from using it at Rdio 15 years ago.

Nothing since (Gerrit, Reviewboard, Github, Critique) has measured up...

My understanding was that that was more a function of how arc submitted stuff to Phabricator, rather than solely Phabricator itself. arc at submission time submitted a bunch of different commits as a single Phabricator DREV or whatever the terminology is/was (basically a DREV is the {domain}/D123 webpage you'd do a review on). But other tools that submitted commits to Phabricator instances (and maybe even arc itself with the right flag?) submitted each commit as its own separate DREV, so each commit got its own separate /D{N} page and its own review, but all linked together in a stack. And then still landed as separate commits in the actual repo. This is how code submission works with Mozilla's use of Phabricator.

Good. That's the point.