Pushed. Thanks!

Pushed. Thanks!

If backward compatibility is a concern, then there are way too many places that need change.

No, hg-experimental didn't care about compatibility with older Mercurial. Otherwise the code would be a mess.

Pushed these. Thanks!

LGTM

Pushed. Thanks!

Thanks for the change! A more common way to handle this is to catch ImportError to detect old versions, and try to deal with the divergence at import time:

Pushed. Thanks!

To clarify, I do think stateless API is better. It can be done by keeping _lastannotate as a private cache inaccessible from other APIs, move annotateresult to the return value of annotate, then add arev to replacelines to verify the cache. The C code use brev instead of rev as the parameter name for a reason.

Pushed. Thanks!

--stack should work as expected if dependency is set manually.

In D4049#63026, @martinvonz wrote:

Sorry, I was just misremembering that D4052 had been queued. I don't know why phabricator doesn't understand that this patch is on top of D4052. Anyway, try applying D4052 first, then this one.

I'd also like to see C linelog benchmark data mentioned. The current commit message implies diff algorithm is the bottleneck. That's misleading.

I would mention in the commit message that building cache is much faster with linkrevcache prebuilt.

I think a most flexible solution is to not do the check if there is nothing to rebase.

FB has users reporting they need to split commits in the middle of a histedit. So this might be too restrictive.

Yeah, if only there is a json.loadb function. That could replace json.loads at line 211. I guess it could be done by using a function that recursively convert strings.

Pushed. Thanks!

Not directly related to this patch. On API complexity: One of the unimplemented ideas is to require a transaction and make operation optional - default to the transaction name.

Pushed. Thanks!

In D3665#58932, @johnstiles wrote:

Looks like your font is missing the dashed vertical line, and has an oddly small regular-circle glyph. I don't recognize the font at all so I can't really speak much more to that. Fortunately though...
(a) it's an extension which isn't on by default
(b) your font choices are your own. That doesn't look like any default font I've ever seen, so this is unlikely to affect many others

Since you mentioned Linux... Here is what your extension renders on my Linux terminal:

To be clear, I have no interest in +1 or -1 this feature, and I'm not interested in spending more time testing it. I think I have made it very clear that Windows (at least WSL) is going to be a headache. Not to say, Linux (as my primary OS) font rendering is another story that might surprise you.

In D3665#58864, @johnstiles wrote:

Are you capable of running the extension?
The output of type is irrelevant to me. The behavior of python.exe when outputting to the Windows shell is all that really matters here. If encoding.encoding reports UTF8, it should work or there's an Hg issue. If it reports something else, the extension will disable itself anyway.

In D3665#58862, @johnstiles wrote:

Without more context I have no idea what you are trying to show. Windows is
certainly capable of rendering Unicode characters in the console. It is
also very possible to get ? characters if you're running a
non-Unicode-aware tool or if there are encoding mix-up issues. "type con"
and pasting in text from a text editor doesn't really prove anything one
way or the other. (What editor? What encoding did it think the data was?
How does "type con" handle Unicode text? etc.)
Run the actual hgext and take a screenshot of what it generates if you want
to give a more useful data point for us.

In D3665#58860, @johnstiles wrote:

What are you trying to demonstrate here? I'm lost.

Maybe I should change cmd.exe font. But here's what I got pasting the text into the console:

Pushed. Thanks for keeping obsshelve up-to-date!

Pushed. Thanks!