durin42

I asked sometime in 2024 and I got a pretty clear response that local/self hosting is not planned.

> That's how I look when I'm excited

I can confirm this (we've worked together)

1) hg absorb

2) hg-git exists, and there's other things afoot that should be better

Please feel encouraged to report a bug about histedit slowness with some details so we can try and reproduce and consider a fix.

Piper still exists, but Mercurial is a viable client tool to interact with Piper's version history.

How long ago was this? And what OS? I know we're faster than unzip on some platforms, but IIRC we just found a pretty awful performance issue on...linux? I think?... that meant our parallelized approach to writing files was burning a ton of time in the kernel filesystem locks or something.

> rewrite a large part of hg in Rust

That's not really the right story. The motivating factor is that we'd like to write /less C/, not /less Python/. It's likely in the long-term that parts of the code that are performance sensitive will move out of Python, but we've been doing that for years, and we just keep finding new things to optimize as the scale of Mercurial repositories keeps increasing.

Last I knew it worked fine, but hg doesn't tend to run long enough for the JIT to warm up enough and be an unambiguous win. Fijal complemented us on how good our C was.

I think it does work if you do chg with a commandserver in pypy.

Go isn't really a huge win for hg, and it doesn't support being used as a shared library, so we couldn't easily use it as a replacement for C for native extensions. main() has to be in Go, and even then you've got two GCs in the mix which is not great.

There's pretty broad consensus that we'd like to do Rust and not C for future extension work, but the current plan is that a pure-Python hg will also be something we support. The "rust binary that embeds Python" approach looks like a straightforward win on Windows, where we have a native .exe that embeds Python anyway. I'm not sure if that'll make sense on non-Windows, but we'll see.

I've done some poking around with milksnake, which seems extremely promising for writing native speedups.

All the communities I know that are centered around diff-in-email patch review are quite frustrated by the available GUI tools (most of them are only good for one patch at a time, or treat an entire stack of patches as one change). If you get somewhere with this, let me know? We might be interested in testing it on Mercurial depending on how it integrates with the email side...