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. 22 Oct, 2020 1 commit
  2. 09 Oct, 2020 1 commit
  3. 17 Jul, 2020 1 commit
  4. 01 Jun, 2020 2 commits
    • Manuel Jacob's avatar
      absorb: make it explicit if empty changeset was created · f55099982bc5
      Manuel Jacob authored
      If the config rewrite.empty-successor=skip is set, a message "became empty and
      was dropped" is shown if the changeset became empty. If the config
      rewrite.empty-successor=keep is set, absorb may create changesets even if they
      became empty. It’s probably a good idea to make that explicit. Therefore the
      message is changed to be a combination of both: "became empty and became ...".
      Repeating the word "became" is not very elegant. This results from the fact
      that "became" was and is overloaded to indicate both the change from non-empty
      to empty and the successor relation. In the combinated message, both meanings
      are used in one sentence.
    • Manuel Jacob's avatar
      absorb: consider rewrite.empty-successor configuration · 3ee8e2d5c0d8
      Manuel Jacob authored
      This adds support for the recently added rewrite.empty-successor configuration.
  5. 27 Dec, 2019 1 commit
  6. 20 Jun, 2020 1 commit
  7. 01 Jun, 2020 3 commits
    • Manuel Jacob's avatar
      absorb: preserve changesets which were already empty · 1ca0047fd7e1
      Manuel Jacob authored
      Most commands in Mercurial (commit, rebase, absorb itself) don’t create empty
      changesets or drop them if they become empty. If there’s a changeset that’s
      empty, it must be a deliberate choice of the user. At least it shouldn’t be
      absorb’s responsibility to prune them. The fact that changesets that became
      empty during absorb are pruned, is unaffected by this.
      This case was found while writing patches which make it possible to configure
      absorb and rebase to not drop empty changesets. Even without having such config
      set, I think it’s valuable to preserve changesets which were already empty.
    • Manuel Jacob's avatar
      absorb: preserve branch-closing changesets even if empty · bfef35bb4ecb
      Manuel Jacob authored
      This makes the behavior consistent with 'hg commit', which allows to create
      otherwise empty changesets if they close the branch. A lost branch closure can
      inadvertently re-open a branch, so it should be preserved.
    • Manuel Jacob's avatar
      absorb: preserve branch-changing changesets even if empty · 1b757f385549
      Manuel Jacob authored
      This makes the behavior consistent with 'hg commit', which allows to create
      otherwise empty changesets if the branch changes compared to the parent. A
      branch change can denote important information, so it should be preserved.
  8. 07 Oct, 2019 1 commit
  9. 11 Jun, 2019 1 commit
  10. 16 Jan, 2019 1 commit
  11. 20 May, 2019 1 commit
  12. 06 Oct, 2019 3 commits
    • Gregory Szorc's avatar
      py3: define and use pycompat.iteritems() for hgext/ · 649d3ac37a12
      Gregory Szorc authored
      .iteritems() -> .items() is the last source transform being performed.
      But it is also the most widely used.
      This commit adds a pycompat.iteritems symbol and imports it in place
      of .iteritems() for usage in hgext/. I chose to stop at just hgext/
      because the patch will be large and it is an easy boundary to stop at
      since we can disable source transformation on a per-package basis.
      There are places where the type does implement items() and we could
      call items() directly. However, this would require critical thought
      and I thought it would be easier to just blindly change the code. We
      know which call sites need to be audited in the future because they
      have "pycompat.iteritems."
      With this change, we no longer perform source transformation on
      Differential Revision:
    • Augie Fackler's avatar
      formatting: byteify all mercurial/ and hgext/ string literals · 687b865b95ad
      Augie Fackler authored
      Done with
          python3.7 contrib/ -i $(hg files 'set:mercurial/**.py - mercurial/thirdparty/** + hgext/**.py - hgext/fsmonitor/pywatchman/** - mercurial/')
          black -l 80 -t py33 -S $(hg files 'set:**.py - mercurial/thirdparty/** - "contrib/python-zstandard/**" - hgext/fsmonitor/pywatchman/**')
      # skip-blame mass-reformatting only
      Differential Revision:
    • Augie Fackler's avatar
      formatting: blacken the codebase · 2372284d9457
      Augie Fackler authored
      This is using my patch to black
      ( so we don't un-wrap collection
      Done with:
        hg files 'set:**.py - mercurial/thirdparty/** - "contrib/python-zstandard/**"' | xargs black -S
      # skip-blame mass-reformatting only
      # no-check-commit reformats foo_bar functions
      Differential Revision:
  13. 16 Apr, 2019 1 commit
  14. 06 Mar, 2020 1 commit
  15. 31 Jan, 2020 1 commit
  16. 28 Feb, 2019 4 commits
  17. 23 Feb, 2019 1 commit
  18. 17 Jan, 2019 1 commit
  19. 14 Dec, 2018 1 commit
  20. 09 May, 2019 1 commit
    • Martin von Zweigbergk's avatar
      absorb: be more specific when erroring out on merge commit · b3fc78c028ef
      Martin von Zweigbergk authored
      When you have a merge commit checked out and run `hg absorb`, it would
      tell you
        abort: no mutable changeset to change
      That makes it sound like the problem is public commits when isn't
      really. Let's be more specific in this case.
      There was already a test case that test this, so that now prints the
      new message. I added a new test case that shows the old message (when
      a public commit is checked out).
      Differential Revision:
  21. 12 Oct, 2018 1 commit
  22. 13 Oct, 2018 1 commit
  23. 12 Oct, 2018 5 commits
  24. 23 Sep, 2018 1 commit
  25. 05 Sep, 2018 1 commit
  26. 09 Aug, 2018 2 commits
  27. 06 Aug, 2018 1 commit