Skip to content
Snippets Groups Projects
  1. Sep 13, 2019
    • Martin von Zweigbergk's avatar
      narrow: don't hexify paths and double-hexify known nodes on wire (BC) · c2676b5a
      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: https://phab.mercurial-scm.org/D6851
      c2676b5a
  2. Sep 15, 2019
  3. Sep 14, 2019
  4. Sep 09, 2019
  5. Aug 01, 2019
    • Martin von Zweigbergk's avatar
      relnotes: copy "next" to "5.1" and clear "next" · cba59b33
      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
      that.
      
      Differential Revision: https://phab.mercurial-scm.org/D6705
      cba59b33
  6. Jul 09, 2019
  7. Jul 08, 2019
    • Kyle Lippincott's avatar
    • Martin von Zweigbergk's avatar
      py3: don't run source transformer on hgext3rd (extensions) · d28d91f9
      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 "extensions.foo=",
      but not as "extension.foo=/some/path".
      
      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: https://phab.mercurial-scm.org/D6614
      d28d91f9
  8. Jun 30, 2019
  9. Jun 28, 2019
  10. Jun 20, 2019
  11. Jun 18, 2019
  12. Apr 18, 2019
    • Martin von Zweigbergk's avatar
      templatekw: make {file_*} compare to both merge parents (issue4292) · 0c72eddb
      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: https://phab.mercurial-scm.org/D6369
      0c72eddb
  13. May 24, 2019
  14. May 16, 2017
  15. May 15, 2017
    • Martin von Zweigbergk's avatar
      match: use '' instead of '.' for root directory (API) · 27d6956d
      Martin von Zweigbergk authored
      I think '' is generally a better value for the root directory than '.'
      is. For example, os.path.join('', 'foo') => 'foo', while
      os.path.join('.', 'foo') => './foo'.
      
      This patch mostly makes it so we use '' internally in
      match.py. However, it also affects the API in visitdir(),
      visitchildrenset() and files(). The two former now also accept '' as
      input. I've updated the callers of these methods. I've also added a
      deprecation warning for passing '.' (for external callers). The only
      caller I could find that was affected by files() returning '' instead
      of '.' was in dirstate.walk(). I've updated that.
      
      The next few patches show some workarounds we can remove by using ''
      instead of '.'.
      
      Differential Revision: https://phab.mercurial-scm.org/D6401
      27d6956d
  16. May 17, 2019
  17. May 01, 2019
    • Martin von Zweigbergk's avatar
      log: add config for making `hg log -G` always topo-sorted · 604c086d
      Martin von Zweigbergk authored
      I (and everyone else at Google) have an log alias that adds graph mode
      and templating. I have another one that builds on the first and also
      restricts the set of revisions to only show those I'm most likely to
      care about. This second alias also adds topological sorting. I still
      sometimes use the first one. When I do, it very often bothers me that
      it's not topologically sorted (branches are interleaved). This patch
      adds a config option for always using topological sorting with graph
      log.
      
      The revision set is sorted eagerly, which seems like a bad idea, but
      it doesn't seem to make a big difference in the hg repo (150ms). I
      initially tried to instead wrap the user's revset in sort(...,topo),
      but that seemed much harder.
      
      Differential Revision: https://phab.mercurial-scm.org/D6331
      604c086d
  18. May 02, 2019
    • Martin von Zweigbergk's avatar
      releasenotes: add a file in which to record release notes · 0ed293a3
      Martin von Zweigbergk authored
      I've just spent a few very boring hours going through the changelog
      for the 5.0 release (829 commits). We only had 5 commits that used the
      syntax that the release notes extension expects. This commit adds a
      file in which we can record important changes. The file should
      preferably be edited in the patch that makes the important change, but
      it can also be edited after (I think this is an important benefit
      compared to the release notes extension).
      
      I'm thinking that we can rename the file from "next" to "5.1" or
      something when it's time, and then we'd create a new "next" file on
      the default branch.
      
      I've used the syntax that we use on the our wiki in the template, but
      I don't care much that we use any valid syntax at all. The idea is
      mostly to record important changes when they happen. I expect that
      some copy editing will be needed at release time anyway.
      
      Differential Revision: https://phab.mercurial-scm.org/D6332
      0ed293a3
Loading