Skip to content
Snippets Groups Projects
  1. May 31, 2022
  2. May 30, 2022
    • Pierre-Yves David's avatar
      debugindex: rename to debugindex debug-revlog-index · db19f6be
      Pierre-Yves David authored
      The command dump some content of the revlog index and omit a lot of
      information. I am going to make it display the missing information.
      
      For clarity, we rename the command to explicitly mention revlog.
      db19f6be
    • Manuel Jacob's avatar
      node: stop converting binascii.Error to TypeError in bin() · 63fd0282
      Manuel Jacob authored
      Changeset f574cc00831a introduced the wrapper, to make bin() behave like on
      Python 2, where it raised TypeError in many cases. Another previous approach,
      changing callers to catch binascii.Error in addition to TypeError, was backed
      out after negative review feedback [1].
      
      However, I think it’s worth reconsidering the approach. Now that we’re on
      Python 3 only, callers have to catch only binascii.Error instead of both.
      Catching binascii.Error instead of TypeError has the advantage that it’s less
      likely to cover a programming error (e.g. passing an int to bin() raises
      TypeError). Also, raising TypeError never made sense semantically when bin()
      got an argument of valid type.
      
      As a side-effect, this fixed an exception in test-http-bad-server.t. The TODO
      was outdated: it was not an uncaught ValueError in batch.results() but uncaught
      TypeError from the now removed wrapper. Now that bin() raises binascii.Error
      instead of TypeError, it gets converted to a proper error in
      wirepeer.heads.<locals>.decode() that catches ValueError (superclass of
      binascii.Error). This is a good example of why this changeset is a good idea.
      Catching TypeError instead of ValueError there would not make much sense.
      
      [1] https://phab.mercurial-scm.org/D2244
      63fd0282
  3. Jun 02, 2022
  4. May 04, 2022
    • idlsoft's avatar
      narrow_widen_acl: enforce narrowacl in narrow_widen (SEC) · 6b10151b
      idlsoft authored
      Reviewer note: this was sent by the author as a simple bugfix, but can be
      considered a security patch, since it allows users to access things outside
      of the ACL, hence the (SEC) prefix.
      
      However, this affects the `narrow` extention which is still marked as
      experimental and has relatively few users aside from large companies with
      their own security layers on top from what we can gather.
      We feel (Alphare: or at least, I feel) like pinging the packaging list is
      enough in this case.
  5. May 27, 2022
  6. May 29, 2022
  7. May 20, 2022
  8. May 19, 2022
  9. Apr 21, 2022
  10. May 18, 2022
  11. May 25, 2022
  12. May 24, 2022
  13. May 22, 2022
  14. Apr 05, 2022
  15. Mar 22, 2022
  16. Apr 05, 2022
  17. May 02, 2022
  18. May 19, 2022
  19. May 17, 2022
  20. May 16, 2022
    • Pierre-Yves David's avatar
      fix-ci: backed out changeset 308e45f7b455 · 22279b60
      Pierre-Yves David authored
      The  chg variant of the CI see a failure on `tests/test-narrow-pull.t`.
      Bisecting point the failure as starting at this small changeset…
      
      Backing it out, restore the CI on default. It was never broken on
      stable, which is even more puzzling.
      22279b60
  21. May 12, 2022
    • Kyle Lippincott's avatar
      amend: stop specifying matcher, get all copies in wctx · df68d64b
      Kyle Lippincott authored
      When we're recreating the commit that we'll be committing, we don't want to
      filter our copy information based on just the *new* [versions of the] files
      we're amending. The test has an example of this case, but for clarity, the
      situation is:
      
      ```
      $ hg cp src dst && hg commit
      <do some work>
      $ hg amend some_unrelated_file.txt
      $ hg status --copies
      A dst
      A some_unrelated_file.txt
      ```
      
      What *should* happen is that `dst` should remain marked as a copy of `src`, but
      this did not previously happen. `matcher` here only includes the files that were
      specified on the commandline, so it only gets the copy information (if any, in
      this example there's not) for `some_unrelated_file.txt`. When it goes to apply
      the memctx to actually create the commit, the file copy information is
      incomplete and loses the information for the files that shouldn't have been
      affected at all by the amend.
      
      Differential Revision: https://phab.mercurial-scm.org/D12625
      df68d64b
Loading