- 26 Jul, 2020 1 commit
-
-
Yuya Nishihara authored
--HG-- branch : stable
-
- 22 Jul, 2020 1 commit
-
-
Matt Harbison authored
The former was dropped in 5.5, and the latter has been around since 4.1.
-
- 21 Jul, 2020 7 commits
-
-
muxator authored
Before this change, dragging & dropping repositories across groups in the registry was not working on py3: at drop, the message b'Start tag expected.' was printed in the console, but nothing happened. The reason is that QMimeData::data() returns a QByteArray containing an XML document that was passed through str() and directly fed to repotreemodel.readXml(), which instead expects either a unicode string or bytes. This change converts the QByteArray to bytes(), and restores the drag & drop functionality in the Repo Registry. --HG-- branch : stable
-
muxator authored
If a user aliased "hg log" to "hg log --graph" (apparently this is widespread, see [0]), the filter toolbar (CTRL+S), is no longer usable. The reason is that, under the hood, the filter toolbar parses the textual output of hg log, which would now be modified by the aliasing [1]. This change undoes any aliasing of hg log, which reverts back to a well-defined format, ensuring the parsing always succeeds. The fix comes from a suggestion by Yuya: https://groups.google.com/forum/#!msg/thg-dev/CTS0X7KYH_8/Qrz1e-gFAgAJ [0] https://www.mercurial-scm.org/repo/hg/rev/604c086ddde6f40309c03ae7e5050c7c8d87e75a [1] For example, looking for head() in the filter toolbar caused this error: Traceback (most recent call last): File "<base>/tortoisehg/hgqt/repomodel.py", line 350, in _onQueryFinished revs = pycompat.maplist(int, bytes(sess.readAll()).splitlines()) ValueError: invalid literal for int() with base 10: 'o 19186' Where the 'o' comes from the graphlog.
-
Manuel Jacob authored
Nosetests is not actively developed anymore. Pytest is actively developed and has a much larger ecosystem around it. Two features of pytest are particularly helpful for us: Pytest captures stdio by redirecting at the file descriptor-level instead of replacing sys.stdout. This is required for Mercurial, as it has its own reference to stdout. Before with nosetests, most output was silently swallowed. Pytest offers the `ALLOW_UNICODE` and `ALLOW_BYTES` options for doctests, making it much easier to make our docstrings Python 2- and Python 3-compatiable. During this patch, it was attempted to leave the structure of the test code similar to before instead of converting everything to idiomatic pytest code. Luckily, pytest implements enough interoperability for most of our test code.
-
Manuel Jacob authored
-
Manuel Jacob authored
-
Manuel Jacob authored
Nosetests treats both the same way. Pytest only understands `setup_module()`. In addition, one `teardown()` was renamed to `teardown_module()`.
-
Yuya Nishihara authored
-
- 20 Jul, 2020 1 commit
-
-
Manuel Jacob authored
Mercurial changeset b1e51ef4e536 changes `phases.phasenames` to be a dict, so it’s not longer slicable. However, there’s also `phases.cmdphasenames`, which contains what we need.
-
- 14 Jul, 2020 7 commits
-
-
Yuya Nishihara authored
-
Manuel Jacob authored
--HG-- branch : stable
-
Manuel Jacob authored
--HG-- branch : stable
-
Manuel Jacob authored
--HG-- branch : stable
-
Manuel Jacob authored
--HG-- branch : stable
-
Manuel Jacob authored
--HG-- branch : stable
-
Manuel Jacob authored
This way, `testedwith` can be queried without having to install additional packages. --HG-- branch : stable
-
- 13 Jul, 2020 3 commits
-
-
Yuya Nishihara authored
Follows up 5735ba9753e1.
-
Manuel Jacob authored
-
Manuel Jacob authored
-
- 11 Jun, 2020 2 commits
-
-
Manuel Jacob authored
The compatibility code masked some py3 errors. --HG-- branch : stable
-
Manuel Jacob authored
--HG-- branch : stable
-
- 19 Jul, 2020 3 commits
-
-
alexrayne authored
--HG-- branch : stable
-
Yuya Nishihara authored
--HG-- branch : stable
-
Yuya Nishihara authored
--HG-- branch : stable
-
- 18 Jul, 2020 1 commit
-
-
Matt Harbison authored
I'm not opposed to keeping the old website, but it hasn't been updated in awhile, and I'm not sure who has access other than Steve. --HG-- branch : stable
-
- 10 Jul, 2020 2 commits
-
-
Matt Harbison authored
The issue linked doesn't seem related to the words around it, and I can't find anything relevant on Heptapod. --HG-- branch : stable
-
Matt Harbison authored
There are many more references in doc/ and i18n. I don't know if we should just do a global find and replace to not break translations, or not care too much because it may already be broken. --HG-- branch : stable
-
- 15 Jul, 2020 1 commit
-
-
Matt Harbison authored
--HG-- branch : stable
-
- 04 Jun, 2020 4 commits
-
-
Manuel Jacob authored
I fail to understand how the code duplication could be solved cleanly by using combined try/except/finally clauses, so I’m not taking further action.
-
Manuel Jacob authored
The only change in the shlex module in the whole Python 2.7 branch is unrelated. Non-ASCII unicode still doesn’t work on Python 2.7.18.
-
Manuel Jacob authored
-
Manuel Jacob authored
Mercurial nowadays requires at least Python 2.7 and imports the ssl module in setup.py, so it would fail if not present.
-
- 10 Jul, 2020 2 commits
-
-
Yuya Nishihara authored
-
Yuya Nishihara authored
--HG-- branch : stable
-
- 29 Jun, 2020 1 commit
-
-
Matt Harbison authored
This represents both a file format and host change. The file on the server was copied from a source used to advertise core Mercurial installers, so we're reusing existing conventions. It has a distinct pattern for WOW64 User-Agents vs 64bit ones. (Currently, both patterns point to the same file.) Yuya expressed concern about blindly using regex patterns from the server, so there's a check to filter out anything that's not trivial. I toyed with the idea of just checking substrings in each pattern, but it got hard to cover all of the cases that the pattern matching provides. For example x86 Windows needs to know about x64 Windows in order to actively ignore x64 packages. With pattern matching, x86 Windows only needs to know about itself when emulating the User-Agent. I also toyed with the idea that matching any OS substring was OK (e.g. any pattern containing "Windows"). But that won't work because I can eventually see x86 Windows being frozen in time at the last version, and it would be annoying if the x86 builds reported an update anyway. Either of those rejected options could mean extra coordination with any changes to the file on the server. Overall, it seems better to have a single, unified method of checking for upgrades from web browsers and the application, especially because there's enough I forget about doing the package uploads once per month already. There is near-identical code in the bugreporter module, but I don't see an obvious, shareable place to store this code. The existing version modules seem minimal by design, and various other util modules seem even less related. --HG-- branch : stable
-
- 11 Jun, 2020 1 commit
-
-
Manuel Jacob authored
The original motivation was to fix the calculation of what leads to "Not a head revision!" warnings in several places, which were all different and flawed in different ways. When thinking about how to fix them, deeper problems surfaced. The previous code showed "Not a head revision!" on the working directory line in the log, which is actually incorrect, as a working directory, when being committed, always becomes a head, as a freshly created revision trivally can’t have any children. Obviously, the label "Not a head revision!" was meant to refer to the working directory parent instead of the working directory. In addition to being at the wrong place, it also broke down for merges, where there are two working directory parents. E.g. when merging the heads of two differently named branches, it incorrectly showed the warning. Because the working directory pseudo-revision is about what happens when committing, a "Creates new head!" warning makes more sense. The logic for determining whether to show this warning is based on that from the `hg commit` command to determine whether to show "created new head". In the commit widget, it could be argued that the "Not a head revision!" warning was not at the wrong place, as it could refer to the parent(s) above the warning instead of to the working directory. Still, it didn’t quite make sense when merging two parents, where it’s not clear which parent it refers to. Also, the previous calculation used a definition of "head" which doesn’t match Mercurial’s. With this patch, it’s clarified that the commit widget is about the working directory. Therefore the warning and calculation is changed to be the same as in the log widget. These changes also make sense from a usability perspective. The user doesn’t need to be warned that they checked out a revision that is not a head. Instead, the user should be warned against creating a new head, as that is often undesirable. Similarly, instead of showing that the working directory parent is closed, we show if a closed branch head is reopened. Again, we use the same logic as the `hg commit` command. When amending a revision that is not a topological head, there is now a note that it will create orphans. In practice, I found this to be a much more valueable information than whether it creates an additional head. See the added comment for detailed reasoning. A few other places had to be changed to be consistent. One notable exception is the backout dialog, where the warning stayed "Not a head, backout will create a new head!". It already had the advantages of the new warning and it was clear which revision "not a head" refers to. The calculation still had to be fixed. For my taste, the patch is a bit too big. However splitting in into smaller parts would have risked that intermediate states would have even more inconsistencies.
-
- 14 Jun, 2020 1 commit
-
-
Manuel Jacob authored
It’s the widget which is shown above the commit message field. Currently, it shows only information about the parents of the working directory, but a subsequent patch will change that.
-
- 11 Jun, 2020 1 commit
-
-
Manuel Jacob authored
-
- 06 Jun, 2020 1 commit
-
-
Yuya Nishihara authored
-