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

  1. 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
      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
      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
  2. 29 Apr, 2020 1 commit
  3. 30 Jan, 2020 2 commits
  4. 08 Dec, 2019 1 commit
  5. 30 Jan, 2020 1 commit
  6. 07 Dec, 2019 1 commit
  7. 31 Aug, 2019 1 commit
  8. 26 Aug, 2019 1 commit
  9. 25 Aug, 2019 1 commit
    • kiilerix's avatar
      assert: try to show some relevant value when an assert fails · 54976f208547
      kiilerix authored
      Debugging and print statements can tell more about failing asserts, but it is
      nice to get *some* information up front, also to make it easier to reproduce.
      General guidelines:
      Try to avoid anything that must compute something and thus can fail - try to
      just inspect local variables (or whatever assert looked at).
      For type related asserts, try to add repr().
      Sometimes, multiple variables are relevant - in that case use tuples.
  10. 01 Jun, 2019 1 commit
  11. 19 May, 2019 1 commit
    • Matt Harbison's avatar
      py3: migrate unicode() to pycompat.unicode() · 6a0080d4e5a5
      Matt Harbison authored
      Fixed up after running `2to3 -w -n -f unicode .`, and re-adding the dropped u''
      prefixes.  The pycompat.unicode() hack is copied into because that
      module declares the dependency on mercurial.
  12. 24 Mar, 2019 1 commit
  13. 05 May, 2019 1 commit
  14. 22 May, 2018 1 commit
  15. 22 Apr, 2018 1 commit
  16. 14 Apr, 2018 1 commit
  17. 06 Jan, 2018 1 commit
  18. 22 Jul, 2017 1 commit
  19. 25 Sep, 2016 1 commit
  20. 08 Feb, 2015 1 commit
  21. 03 Aug, 2014 2 commits
  22. 10 Aug, 2015 1 commit
  23. 31 Jan, 2014 1 commit
    • Yuya Nishihara's avatar
      csinfo: handle lookup error caused by pre-commit branch name · a44494d99209
      Yuya Nishihara authored
      If ctx points to null or working-copy revision, its branch name may not
      exist in the repository.  In that case, get_data('branch') should be empty
      because it isn't a branch-head revision.
      This fixes the following exceptions::
          # update of empty repository
          Traceback (most recent call last):
            File "tortoisehg/hgqt/", line 349, in __init__
              self.setCommandWidget(UpdateWidget(repoagent, rev, self, opts))
            File "tortoisehg/hgqt/", line 111, in __init__
            File "tortoisehg/hgqt/", line 175, in preset_func
              if ctx.node() != repo.branchtip(ctx.branch()):
            File "mercurial/", line 668, in branchtip
              raise error.RepoLookupError(_("unknown branch '%s'") % branch)
          RepoLookupError: unknown branch 'default'
          # graft on new working-copy branch
          Traceback (most recent call last):
            File "tortoisehg/hgqt/", line 1819, in graftRevisions
              dlg = graft.GraftDialog(self._repoagent, self, source=revlist)
            File "tortoisehg/hgqt/", line 76, in __init__
              self.source = csinfo.create(self.repo, None, style, withupdate=True)
            File "tortoisehg/hgqt/", line 175, in preset_func
              if ctx.node() != repo.branchtip(ctx.branch()):
            File "mercurial/", line 668, in branchtip
              raise error.RepoLookupError(_("unknown branch '%s'") % branch)
          RepoLookupError: unknown branch 'foo'
      This bug was introduced by 74bbd0b3d1b7.
      branch : stable
  24. 21 Dec, 2013 1 commit
  25. 20 Nov, 2013 1 commit
  26. 22 Sep, 2013 1 commit
  27. 19 Sep, 2013 1 commit
  28. 23 Aug, 2013 1 commit
  29. 29 Aug, 2013 1 commit
    • Angel Ezquerra's avatar
      csinfo: show 'Original Parent' field for patches when necessary · d6aa71602652
      Angel Ezquerra authored
      The 'Original Parent' field shows the revision info of the revision on top of
      which a particular patch was originally applied.
      This field will only be shown for unapplied patches and for applied patches
      whose original parent does not match their current parent. In addition, it will
      only be shown if the Original Parent is a valid revision on the repository.
      This revision requires reading the header of applied patches, which may have
      some performance impact (particularly if the repository is on a network drive).
      If that ever happens we'll have to add some sort of catching, but it will have
      to be done at the repo level, since context objects are created on each
      repo[changeid] call.
  30. 26 Jun, 2013 1 commit
  31. 22 Jun, 2013 1 commit
    • Angel Ezquerra's avatar
      csinfo: add "obsolete" field · 0ed187550918
      Angel Ezquerra authored
      This field can show the obsolete "state" of a changeset. By "obsolete state" we
      refer to any obsolete/changeset evolution related "flag", such as whether the
      revision is obsolete, extinct or has some obsolete "trouble" (such as it being
      divergent, bumped or unstable).
      The list of "states" is shown as a list of strings, each with a light red
      This is not used yet, but it will be enabled in a following changeset.
  32. 15 Jun, 2013 1 commit
  33. 17 Feb, 2013 1 commit
    • Steve Borho's avatar
      pyqt: make workbench and commit tool work with PyQt 4.6 (CentOs 6.3) · 8d357e3ae4d8
      Steve Borho authored
      This mainly involved removing some keyword arguments to Qt functions,
      catching some missing Lexers, and a handful of missing methods.  The
      biggest loss is the XML reader for the registry is gone; so the registry
      itself is mostly useless.  On the grand scale of things, this isn't too
      branch : stable
  34. 17 May, 2012 1 commit
  35. 15 Dec, 2011 1 commit
  36. 06 Aug, 2011 1 commit
  37. 16 Apr, 2011 1 commit
  38. 25 May, 2011 1 commit