This instance will be upgraded to Heptapod 0.21.0rc2 on 2021-04-16 at 14:00 UTC+2 (a few minutes of down time)

  1. 26 Jul, 2020 1 commit
  2. 22 Jul, 2020 1 commit
  3. 21 Jul, 2020 7 commits
    • muxator's avatar
      py3: fix drag & drop in the Repository Registry · bff76ec4059e
      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
      bff76ec4059e
    • muxator's avatar
      cmdcore: override user aliases on hg log · f9676491ecc7
      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.
      f9676491ecc7
    • Manuel Jacob's avatar
      tests: port from nosetests to pytest · d843f9a62e6e
      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.
      d843f9a62e6e
    • Manuel Jacob's avatar
      hgignore: ignore `.pytest_cache` · 1e10fa7d6bc2
      Manuel Jacob authored
      1e10fa7d6bc2
    • Manuel Jacob's avatar
      tests: drop unused `name` variable · 5d0842c83096
      Manuel Jacob authored
      5d0842c83096
    • Manuel Jacob's avatar
      tests: rename module-level setup function from `setup()` to `setup_module()` · a8cbf1129123
      Manuel Jacob authored
      Nosetests treats both the same way. Pytest only understands `setup_module()`.
      
      In addition, one `teardown()` was renamed to `teardown_module()`.
      a8cbf1129123
    • Yuya Nishihara's avatar
      merge with stable · c59bd6104b8d
      Yuya Nishihara authored
      c59bd6104b8d
  4. 20 Jul, 2020 1 commit
  5. 14 Jul, 2020 7 commits
  6. 13 Jul, 2020 3 commits
  7. 11 Jun, 2020 2 commits
  8. 19 Jul, 2020 3 commits
  9. 18 Jul, 2020 1 commit
  10. 10 Jul, 2020 2 commits
  11. 15 Jul, 2020 1 commit
  12. 04 Jun, 2020 4 commits
  13. 10 Jul, 2020 2 commits
  14. 29 Jun, 2020 1 commit
    • Matt Harbison's avatar
      about: migrate to `latest.dat` on mercurial-scm.org for upgrade checks · 20f9aee27152
      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
      20f9aee27152
  15. 11 Jun, 2020 1 commit
    • Manuel Jacob's avatar
      repomodel, revpanel: improve upon "Not a head revision!" warning · 02bf7e7f2c44
      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.
      02bf7e7f2c44
  16. 14 Jun, 2020 1 commit
    • Manuel Jacob's avatar
      commit: rename ParentWidget to WDirInfoWidget · 0fae0d10114e
      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.
      0fae0d10114e
  17. 11 Jun, 2020 1 commit
  18. 06 Jun, 2020 1 commit