- 11 Apr, 2021 1 commit
-
-
Matt Harbison authored
I noticed this hacking on some other functionality, but it can be seen with an existing command like this when updated to any recent change: $ python thg vdiff -r 5bfef52bfcc9 tortoisehg/hgqt/qsci.py tortoisehg/hgqt/qtcore.py All of the subsequent file copies that took place between then and now get included in the snapshots, even though they weren't related. Two files need to match to invoke a dirdiff, otherwise the snapshot of the unrelated files occurs, but only the named one is diffed. The same behavior occurs if two of the files in the manifest view of that revision are selected and diffed to local. The filtering might still be a little generous in that it matches either the source or destination. But I'm not sure what the data looks like for a diff from new -> old as opposed to old -> new, and order of revision selection might be a little too subtle in the GUI.
-
- 13 Apr, 2021 1 commit
-
-
Yuya Nishihara authored
-
- 11 Apr, 2021 2 commits
-
-
Matt Harbison authored
The --change arg was OK, because that path tests for unicode and conditionally converts from it. The --rev path was broken because it blindly converted, resulting in revision values with a `b''` prefix being looked up and failing. In this case, there was just an Abort messagebox- no traceback, even with the `--traceback` option. --HG-- branch : stable
-
Matt Harbison authored
I hit this when cancelling the discard/merge/shelve popup with a dirty wdir, instead of selecting one of the other buttons. This fixes cb5c5a12f06a. --HG-- branch : stable
-
- 10 Apr, 2021 1 commit
-
-
Matt Harbison authored
This code goes all the way back to c9bc1c7192c2. I'm not sure what's changed, but the values come from `hglib.difftools()`, which in turn comes from `ui.config()`, so it should have always been bytes.
-
- 09 Apr, 2021 1 commit
-
-
Matt Harbison authored
There are a handful of `annotation-type-mismatch` suppressions for constructs like a function's Text arg being immediately overwritten with the bytes form of the argument. This is an experimental diagnostic that needs to be explicitly enabled in pytype (for now), but such uses also seem to confuse PyCharm. It does seem reasonable to overwrite the argument after converting between bytes and unicode, but one such overwrite at the end of the function wasn't as useful, so it has been elided away.
-
- 08 Apr, 2021 1 commit
-
-
Gleb Popov authored
Fixes #5705 --HG-- branch : stable
-
- 09 Apr, 2021 3 commits
-
-
Matt Harbison authored
The default value for the `tag` argument is switched to bytes because the only caller that provides it passes bytes from the command line. This was only working because the `hglib.tounicode()` method it is run through already checks for a unicode arg and returns it unchanged. --HG-- branch : stable
-
Matt Harbison authored
When a local tag was selected from the combobox, the "local tag" checkbox wasn't ticked. --HG-- branch : stable
-
Matt Harbison authored
--HG-- branch : stable
-
- 08 Apr, 2021 1 commit
-
-
Matt Harbison authored
-
- 10 Apr, 2021 1 commit
-
-
Matt Harbison authored
-
- 09 Apr, 2021 2 commits
-
-
Matt Harbison authored
This fixes e98411b0b72e. First, I confused this with `scmutil.revrange()`, which does accept int. Second, `scmutil.revsymbol()` can't return a `patchctx` because it only calls `repo[symbol]` if the symbol is one of a handful of magic strings or a stringified revision. Otherwise, it tries to lookup a node or bookmark name. This popped up when typing the `visdiff` module, because `patchctx` lacks `manifest()` and `ancestor()` functions. The original `ThgContext` is left for the upcoming changes that could also use `patchctx`. IDK if there's a difference between defining these with `TypeVar` or `Union`, but I switched to the latter because PyCharm shows that instead of the custom name. That's better, since it hides the names that aren't really descriptive.
-
Matt Harbison authored
In order to keep an already complicated type for being complicated further, some of the dict values stored are changed from list to tuple to align with other stored values.
-
- 10 Apr, 2021 1 commit
-
-
Yuya Nishihara authored
-
- 08 Apr, 2021 3 commits
-
-
Matt Harbison authored
This matches what is used for core contexts. I'm not sure it actually matters, but after the previous commit mixed patchctx and core contexts as a custom type, PyCharm flagged the `substate` uses in `manifestmodel._populatesubrepos()` as that module was being typed: Expected type 'Iterable[Union[propertycache, property]]' (matched generic type 'Iterable[_T]'), got 'Union[propertycache, property]' instead
-
Matt Harbison authored
Followup to 710c0d416cbd that may mean fewer type assertions or type check suppressions are needed.
-
Yuya Nishihara authored
-
- 07 Apr, 2021 4 commits
-
-
Matt Harbison authored
--HG-- branch : stable
-
Matt Harbison authored
I don't see the point, as the `rev` variable is not subsequently used, and `revsymbol()` already calls `repo[rev]`.
-
Matt Harbison authored
Since the function could theoretically return a workingctx, there are a couple places that need type assertions where attributes are accessed that are not on basectx. Additionally, pytype flagged the mq module for calling a function on the custom context subclass, so that is now suppressed. I'm assuming these context subclass functions would be better off being unbound methods in a `contextutil` module or similar, because the hidden subclass is confusing the typing some times, and it's weird that some functions on a context return unicode.
-
Matt Harbison authored
Unfortunately, this core function can't be typed properly because its module imports the context module, but the function returns a class in the context module. Using this allowed PyCharm to pick up the unicode being passed to the context object in 75a96fd40bde. Pytype didn't flag that because it seems to struggle with recognizing typing on dunder methods, but now knows it is a basectx there.
-
- 06 Apr, 2021 1 commit
-
-
Matt Harbison authored
--HG-- branch : stable
-
- 07 Apr, 2021 1 commit
-
-
Matt Harbison authored
Caught by PyCharm, not pytype. Pytype seems to struggle with understanding what `repo[..]` returns. --HG-- branch : stable
-
- 06 Apr, 2021 1 commit
-
-
Matt Harbison authored
All callers are passing only Text. --HG-- branch : stable
-
- 07 Apr, 2021 1 commit
-
-
Matt Harbison authored
Flagged by PyCharm after the next couple of patches. --HG-- branch : stable
-
- 05 Apr, 2021 5 commits
-
-
Matt Harbison authored
No bug here, but PyCharm flagged the caller that passes 'internal:merge' as giving the wrong type, as well as the inside of the function itself where the value is appended to a str.
-
Matt Harbison authored
Rather than complicate the hints for `_writereviewerhistory()`, drop the empty list that was returned early, and never used by the caller.
-
Matt Harbison authored
-
Matt Harbison authored
I noticed this comparing against `tortoisehg.hgqt.run.run()`. Since `ui` is passed as an argument and there is no `.ui()` on it, this would have crashed. The other use is adjusted accordingly.
-
Matt Harbison authored
This is mostly aligning the command with the similar `tortoisehg.hgqt.run.run()` implementation. There's still something wierd here because it seems like at least some config options aren't being loaded, resulting in a stacktrace when some code unexpectedly gets `None` back. In order show the window, it needs this command line to run with hg 5.7.1 and py 3.8.1: hg.exe --config extensions.hgview=hgext3rd\thg.py view --traceback \ --config tortoisehg.cmdserver.readtimeout=5 \ --config tortoisehg.tasktabs=east \ --config extensions.topic=! \ --config tortoisehg.graphlimit=100 Since stderr isn't wrapped on py3, I have no idea how it's supposed to pop up the error box, but this is how the workbench component is launched, and the popup displays there under py3.
-
- 04 Apr, 2021 1 commit
-
-
Matt Harbison authored
-
- 01 Apr, 2021 1 commit
-
-
Matt Harbison authored
-
- 04 Apr, 2021 1 commit
-
-
Yuya Nishihara authored
-
- 01 Apr, 2021 5 commits
-
-
Matt Harbison authored
Sadly, this isn't caught by pytype. For whatever reason, it thinks that `self._webconf` is `Any`. --HG-- branch : stable
-
Matt Harbison authored
--HG-- branch : stable
-
Matt Harbison authored
--HG-- branch : stable
-
Yuya Nishihara authored
-
Matt Harbison authored
PyCharm was smart enough to detect this. Unfortunately, pytype isn't, unless the config and _wconfig classes subclass `typing.Mapping`. But that code doesn't seem to run on py2, and also isn't quite correct because the config class has a 2 arg `get()` function that returns the byte string value, not the dict of values for each section entry in a normal mapping. --HG-- branch : stable
-
- 31 Mar, 2021 1 commit
-
-
Matt Harbison authored
More fallout from hg d3df397e7a59. The previous code was returning a tuple of the value, source, and level, and because that's != `b''`, the checkboxes for the extensions enabled by the current config page were disabled.
-