Skip to content
Snippets Groups Projects
  1. Dec 05, 2020
  2. Dec 10, 2020
    • Martin von Zweigbergk's avatar
      diff: add --from and --to flags as clearer alternative to -r -r · 64292add
      Martin von Zweigbergk authored
      I think it was mistake to let the `-r` flag accept two revisions in
      `hg diff` in 98633e60067c (Support for 0, 1, or 2 diff revs,
      2005-05-07). The command clearly acts on two revisions and having a
      single flag to indicate which those are is unclear. It got worse when
      it started accepting revsets as input.
      
      This patch introduces `--from` and `--to` flags, each taking a single
      revision and each defaulting to the working copy. That means that `hg
      64292add
  3. Dec 01, 2020
  4. Oct 30, 2020
  5. Nov 08, 2020
  6. Nov 02, 2020
  7. Oct 29, 2020
  8. Oct 17, 2020
  9. Sep 21, 2020
    • Martin von Zweigbergk's avatar
      merge: make low-level update() private (API) · 2c86b958
      Martin von Zweigbergk authored
      We have very few callers left that call the low-level `merge.update()`
      function. I think it's time to make it private. I'll remove the
      remaining callers in coming patches, except for one call from the
      `rebase` module. I hope to eventually fix that too, but it's more
      complex because it requires teaching `merge.graft()` to work with a
      dirty working copy.
      
      Differential Revision: https://phab.mercurial-scm.org/D9065
      2c86b958
  10. Jul 28, 2020
  11. Jul 20, 2020
  12. Jul 18, 2020
  13. Jun 21, 2020
  14. Jun 04, 2020
    • Manuel Jacob's avatar
      perf: make `hg perfwrite` more flexible · c2df0bca
      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`.
      c2df0bca
  15. May 30, 2020
    • sliquister's avatar
      relnotes: advertize the possibility to use rust · f330d611
      sliquister 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: https://phab.mercurial-scm.org/D8604
      f330d611
    • Manuel Jacob's avatar
      setup: require that Python has TLS 1.1 or TLS 1.2 · 95c83284
      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
      problematic:
      https://github.com/python/cpython/commit/6e8cda91d92da72800d891b2fc2073ecbc134d98#r39569316
      95c83284
    • Manuel Jacob's avatar
  16. May 18, 2020
  17. Mar 13, 2020
  18. Feb 29, 2020
  19. Feb 28, 2020
    • Martin von Zweigbergk's avatar
      commit: clear resolved mergestate even if working copy is clean · 6a34e438
      Martin von Zweigbergk authored
      If the mergestate has resolved conflicts and a commit is successfully
      created (either because there are changes in the working copy or
      because ui.allowemptycommit=yes), we will also clear the merge
      state. However, if the working copy is clean (and
      ui.allowemptycommit=no), we leave the mergestate there. The user may
      notice it in `hg resolve -l` output (but not in `hg status -v`
      output). It's not clear how the user should clear it, but probably via
      `hg co -C .`. It's also quite likely that they won't even notice it
      and it will get cleared by a later `hg commit` (of unrelated
      changes).
      
      This patch makes it so that `hg commit` also clears resolved merge
      conflicts even if the command doesn't end up writing a commit because
      the working copy was empty. That's probably a little weird (commands
      that abort should generally avoid changing the repo), but it still
      seems mostly harmless, and it reduces the risk of more bugs like
      https://bz.mercurial-scm.org/show_bug.cgi?id=5494. I just ran into a
      version of that bug in the Evolve extension and that's what triggered
      this series.
      
      Differential Revision: https://phab.mercurial-scm.org/D8196
      6a34e438
  20. Jan 24, 2020
  21. Feb 26, 2020
    • sliquister's avatar
      exchange: turn on option that makes concurrent pushes work better · edc8504b
      sliquister authored
      The motivation is simply to make hg work better out of the box.
      
      This is a slight backwards compatibility break, because client
      extensions could have assumed that the list of heads the client sees
      during discovery will be the list of heads during the entirety of the
      push. It seems unlikely to matter, and not worth mentioning.
      
      There's a fair amount of diff in tests, but this is just due to
      sending a few more bytes on the wire, except for test-acl.t.
      The extra "invalid branch cache" lines in test-acl.t don't seem to
      indicate a problem: the branchcache now get computed during the bundle
      application (because of the check:updated-heads bundle part), but
      doesn't get rolled back when transactions rollback, thus causing a
      message in the next operation computing the branch cache. Before this
      change, I assume the branchcache was only computed on transaction
      commit, so not computed at all when the transactions roll back, thus
      no messages.
      
      Differential Revision: https://phab.mercurial-scm.org/D8202
      edc8504b
    • Martin von Zweigbergk's avatar
      merge: drop redundant mergeforce argument from hg.merge() · ddbc296a
      Martin von Zweigbergk authored
      The only caller that passed a value for either `force` or `mergeforce`
      passed the same value for both, so let's simplify the interface by
      accepting only `force`.
      
      Differential Revision: https://phab.mercurial-scm.org/D8167
      ddbc296a
  22. Feb 14, 2020
    • Martin von Zweigbergk's avatar
      debugmergestate: make templated · acbfa31c
      Martin von Zweigbergk authored
      Our IntelliJ team wants to be able to read the merge state in order to
      help the user resolve merge conflicts. They had so far been reading
      file contents from p1() and p2() and their merge base. That is not
      ideal for several reasons (merge base is not necessarily the "graft
      base", renames are not handled, commands like `hg update -m` is not
      handled). It will get especially bad as of my D7827. This patch makes
      the output s a templated. I haven't bothered to make it complete
      (e.g. merge driver states are not handled), but it's probably good
      enough as a start.
      
      I've done a web search for "debugmergestate" and I can't find any
      indication that any tools currently rely on its output. If it turns
      out that we get bug reports for it once this is released, I won't
      object to backing this patch out on the stable branch (and then
      perhaps replace it by a separate command, or put it behind a new
      flag).
      
      The changes in test-backout.t are interesting, in particular this:
      
      ```
        -    other path: foo (node not stored in v1 format)
        +    other path:  (node foo)
      ```
      
      I wonder if that means that we actually read v1 format
      incorrectly. That seems to be an old format that was switched away
      from in 2014, so it doesn't matter now anyway.
      
      Differential Revision: https://phab.mercurial-scm.org/D8120
      acbfa31c
  23. Feb 26, 2020
  24. Feb 14, 2020
    • sliquister's avatar
      bookmarks: prevent pushes of divergent bookmarks (foo@remote) · 8407031f
      sliquister authored
      Before this change, such bookmarks are write-only: a client can push
      them but not pull/read them. And because these bookmark can't be read,
      even pushes are limited (for instance trying to delete such a bookmark
      fails with a vanilla client because the client thinks the bookmark is
      neither on the local nor the remote).
      
      This change makes the server refuses such bookmarks, and for earlier
      errors, makes the client refuse to send them.
      
      I think the change of behavior is acceptable because I think this is a
      bug in push/pull, and I don't think we change the behavior of `hg
      unbundle`, because it doesn't seem that `hg bundle` ever store
      bookmarks (and even if it did, it would seem weird anyway to try to
      send divergent bookmarks).
      
      Differential Revision: https://phab.mercurial-scm.org/D8117
      8407031f
  25. Feb 15, 2020
  26. Dec 20, 2019
    • Martin von Zweigbergk's avatar
      copy: add experimental support for marking committed copies · 9dab3fa6
      Martin von Zweigbergk authored
      The simplest way I'm aware of to mark a file as copied/moved after
      committing is this:
      
        hg uncommit --keep <src> <dest>  # <src> needed for move, but not copy
        hg mv --after <src> <dest>
        hg amend
      
      This patch teaches `hg copy` a `--at-rev` argument to simplify that
      into:
      
        hg copy --after --at-rev . <src> <dest>
      
      In addition to being simpler, it doesn't touch the working copy, so it
      can easily be used even if the destination file has been modified in
      the working copy.
      
      Differential Revision: https://phab.mercurial-scm.org/D8035
      9dab3fa6
  27. Jan 28, 2020
    • Martin von Zweigbergk's avatar
      copy: add experimetal support for unmarking committed copies · 7c4b98a4
      Martin von Zweigbergk authored
      The simplest way I'm aware of to unmark a file as copied after
      committing is this:
      
        hg uncommit --keep <dest>
        hg forget <dest>
        hg add <dest>
        hg amend
      
      This patch teaches `hg copy --forget` a `-r` argument to simplify that into:
      
        hg copy --forget --at-rev . <dest>
      
      In addition to being simpler, it doesn't touch the working copy, so it
      can easily be used even if the destination file has been modified in
      the working copy.
      
      I'll teach `hg copy` without `--forget` to work with `--at-rev` next.
      
      Differential Revision: https://phab.mercurial-scm.org/D8030
      7c4b98a4
Loading