Oct 3 2018
Sep 13 2018
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!
Sep 4 2018
Aug 29 2018
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:
Aug 14 2018
Aug 9 2018
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.
Aug 7 2018
Aug 6 2018
Aug 3 2018
--stack should work as expected if dependency is set manually.
Aug 2 2018
I'd also like to see C linelog benchmark data mentioned. The current commit message implies diff algorithm is the bottleneck. That's misleading.
Aug 1 2018
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.
Jul 31 2018
FB has users reporting they need to split commits in the middle of a histedit. So this might be too restrictive.
Jul 25 2018
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.
Jul 24 2018
Jul 10 2018
Jun 21 2018
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.
Jun 19 2018
Jun 16 2018
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.
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.
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.
Maybe I should change cmd.exe font. But here's what I got pasting the text into the console:
Jun 15 2018
Pushed. Thanks for keeping obsshelve up-to-date!