Read about our upcoming Code of Conduct on this issue

  1. 28 Jul, 2020 2 commits
  2. 20 Jul, 2020 3 commits
  3. 18 Jul, 2020 1 commit
  4. 18 May, 2020 1 commit
  5. 21 Jan, 2020 1 commit
  6. 27 Dec, 2019 1 commit
    • Martin von Zweigbergk's avatar
      graftcopies: remove `skip` and `repo` arguments · 833210fbd900
      Martin von Zweigbergk authored
      The `skip` argument was added in 2ba6c9b4e0eb (rebase: fix bug that
      caused transitive copy records to disappear (issue4192), 2014-06-07)
      in order to fix I
      ran tests at that commit without the `skiprev` argument and the only
      difference I noticed was that `test-rebase-collapse.t` failed
      differently, in the call that is now on line 501. Without the
      `skiprev` argument, that call would end up creating another commit
      because it tried to record an invalid copy. With the previous patch in
      this series, such invalid copies are no longer recorded, so it seems
      we don't need the `skip` argument anymore.
      I also removed the `repo` argument since that also becomes unused with
      the removal of the `skip` argument.
      Differential Revision:
  7. 06 Jan, 2020 1 commit
  8. 18 Dec, 2019 1 commit
    • Matt Harbison's avatar
      windows: add a global equivalent to /etc/mercurial for *.rc processing · 1ccf340acf14
      Matt Harbison authored
      This follows the Unix model of processing this directory immediately after
      <internal>/*.rc, and prior to the installation relative files.  Since the Unix
      processing supports both a directory and a file (the former overriding the
      latter), and since %HOME% supports both `*.ini` and `.hgrc` (again, the former
      overriding the latter), this does too.  The Unix file doesn't have a `.` prefix,
      so it's not used here either.
      Note that this is the opposite order of processing the exe relative paths.  But
      since it's in agreement with Unix, %HOME% and %USERPROFILE%, it seems reasonable
      to ignore that.  Maybe we can change that and take a BC, because that's
      something the installer should be controlling, and I can't imagine people having
      both paths *and* conflicting settings.
      Differential Revision:
  9. 16 Dec, 2019 1 commit
  10. 05 Nov, 2019 1 commit
  11. 22 Nov, 2019 1 commit
  12. 15 Nov, 2019 1 commit
  13. 21 Jun, 2020 1 commit
  14. 04 Jun, 2020 1 commit
    • Manuel Jacob's avatar
      perf: make `hg perfwrite` more flexible · c2df0bca0dfa
      Manuel Jacob authored
      The more flexible command was used recently while finding a solution for a
      buffering bug (eventually fixed in f9734b2d59cc (the changeset description uses
      a different benchmark)).
      In comparison to the previous version, the new version is much more flexible.
      While using it, the focus was on testing small writes. For this reason, by
      default it calls ui.write() 100 times with a single byte plus one newline byte,
      for 100 lines.
      To get the previous behavior, run `hg perfwrite --nlines=100000 --nitems=1
      --item='Testing write performance' --batch-line`.
  15. 30 May, 2020 3 commits
    • Valentin Gatien-Baron's avatar
      relnotes: advertize the possibility to use rust · f330d6117a5b
      Valentin Gatien-Baron authored
      I think the rust work may have been mentioned in the release notes,
      but if so only in passing, and not as an invitation to try it out.
      I think the next version is a decent time to do this, because the rust
      doesn't come with performance regressions AFAIK, speeds up status
      noticeably when it applies, which is the case for most invocations of
      status, and doesn't have the undesirable restriction of regex around
      empty patterns anymore.
      I am cheating a bit, because I'm giving numbers for `hg status` in
      mozilla-central, but they have one hgignore pattern that uses
      lookaround, ".vscode/(?!extensions\.json|tasks\.json", which I took
      out as it would cause a fallback to python when unknown files are
      requested. But it seems that they could express their hgignore
      differently if they were so inclined.
      Not sure if there are limitation other than linux-only that I am
      not thinking of but would be worth mentioning upfront, to avoid
      disappointing users?
      Differential Revision:
    • Manuel Jacob's avatar
      setup: require that Python has TLS 1.1 or TLS 1.2 · 95c832849955
      Manuel Jacob authored
      This ensures that Mercurial never downgrades the minimum TLS version from
      TLS 1.1+ to TLS 1.0+ and enables us to remove that compatibility code.
      It is reasonable to expect that distributions having Python 2.7.9+ or having
      backported modern features to the ssl module (which we require) have a OpenSSL
      version supporting TLS 1.1 or TLS 1.2, as this is the main reason why
      distributions would want to backport these features.
      TLS 1.1 and TLS 1.2 are often either both enabled or both not enabled.
      However, both can be disabled independently, at least on current Python /
      OpenSSL versions.
      For the record, I contacted the CPython developers to remark that
      unconditionally defining ssl.PROTOCOL_TLSv1_1 / ssl.PROTOCOL_TLSv1_2 is
    • Manuel Jacob's avatar
  16. 18 May, 2020 2 commits
  17. 01 Aug, 2019 1 commit
    • Martin von Zweigbergk's avatar
      relnotes: copy "next" to "5.1" and clear "next" · cba59b338976
      Martin von Zweigbergk authored
      To avoid merge conflicts, we want to avoid modifying the file on
      multiple branches in parallel. This patch is therefore meant to be
      applied to the stable branch and then quickly be merged to default (at
      least before edits are made to relnotes/next there).
      Another option would have been to copy the file on the stable branch
      and to clear it on the default branch. However, that still results in
      conflicts if the copy is edited on the stable branch (Mercurial would
      try to apply the changes from the default branch to it).
      We could also delete the file in one commit and recreate it in another
      commit. However, Mercurial is quite inconsistent in what it considers
      a break in history (see test-copies-unrelated.t), so I'd like to avoid
      Differential Revision:
      branch : stable
  18. 09 Jul, 2019 1 commit
  19. 08 Jul, 2019 2 commits
    • Kyle Lippincott's avatar
    • Martin von Zweigbergk's avatar
      py3: don't run source transformer on hgext3rd (extensions) · d28d91f9f35a
      Martin von Zweigbergk authored
      It's unclear why the source transformer runs on hgext3rd. It's been
      like that since it was introduced in 1c22400db72d (mercurial:
      implement a source transforming module loader on Python 3,
      2016-07-04), and that commit didn't say anything about it (but it says
      that it doesn't have "support [...] for extensions").
      I find that the current handling of hgext3rd just makes it harder to
      convert extensions to Python 3. It makes you convert a bunch of
      strings passed to getattr() and kwargs[] to r'' that could otherwise
      have been left alone. It's also really confusing that the source
      transformer runs when you import the extension as "",
      but not as "".
      I suppose there is small number of (very simple) extensions that would
      have worked without this patch that would now be broken. It seems okay
      to me to break those.
      Differential Revision:
  20. 30 Jun, 2019 1 commit
  21. 28 Jun, 2019 1 commit
  22. 20 Jun, 2019 1 commit
  23. 18 Jun, 2019 1 commit
  24. 13 Mar, 2020 2 commits
  25. 18 Apr, 2019 1 commit
    • Martin von Zweigbergk's avatar
      templatekw: make {file_*} compare to both merge parents (issue4292) · 0c72eddb4be5
      Martin von Zweigbergk authored
      This redefines the {file_adds}, {file_dels}, {file_mods} template
      keywords by getting the lists from the recently introduced context
      methods instead of getting them from status compared to p1. As
      mentioned before, these are better defined on merge commits. The total
      number of files from the three lists now always add up to the number
      of files in {files}.
      I timed this command:
        hg log -r 4.0::5.0 -T '{rev}\n {file_mods}\n {file_adds}\n {file_dels}\n'
      It went from 7.6s to 5.6s with this patch. So it's actually faster
      than before.
      Note that the "files:" field in the bazaar test log output was using
      "{file_mods}" (not "{files}" as one might think based on the label).
      Differential Revision:
  26. 24 May, 2019 1 commit
  27. 13 Sep, 2019 1 commit
    • Martin von Zweigbergk's avatar
      narrow: don't hexify paths and double-hexify known nodes on wire (BC) · c2676b5a9f59
      Martin von Zweigbergk authored
      It isn't obvious, but wireprototypes.encodelist() is meant only for
      binary nodeids. So when we used it for encoding hex nodeids and paths,
      the encoded result was surprising and hard to read.
      This patch changes the encoding to make the list of paths a
      comma-separated list and the list of common nodes to be a
      encodelist()-encoded list of binary nodeids (so the result is just
      singly-hexified nodeids).
      This is clearly a breaking change, but the feature is experimental and
      we're not aware of anyone running a server using this command yet.
      Differential Revision:
  28. 15 Sep, 2019 2 commits
  29. 14 Sep, 2019 1 commit
  30. 09 Sep, 2019 1 commit
  31. 29 Feb, 2020 1 commit