Updated so only dispatch.py patches sys.std* directly

Updated to remove the warning and open a separate stderr.

In D9058#135940, @indygreg wrote:

This looks like a legit bug fix. And when I see patches like this, I wonder what circumstances led to its discovery :p

No, initially because I'd never heard of it, but now because I don't want to deal with ocaml. :)

Have pyre been considered? It seems pyre only takes 10 seconds to check all the .py files.

What do you think about this approach:

You can use rustfmt +nightly if it's installed by rustup. It also runs on Windows.

--rev seems ambiguous since there might be different kinds of revisions to specify - target and revisions to edit. Maybe something like --source, --from, --target?

We actually ran rustfmt, but it's an older version (rustfmt 1.3.0-stable (d334502 2019-06-09)) and I verified the code still formats under that particular version of rustfmt with empty rustfmt.toml. In other words, rustfmt itself seems to change over time.

No longer use this approach.

No longer use this approach.

Took another approach.

No longer needed.

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!