Skip to content
Snippets Groups Projects
  1. Mar 31, 2018
  2. Mar 19, 2018
    • Connor Sheehan's avatar
      templatefuncs: add mailmap template function · 2a2ce93e
      Connor Sheehan authored
      This commit adds a template function to support the .mailmap file
      in Mercurial repositories. The .mailmap file comes from git, and
      can be used to map new emails and names for old commits. The general
      use case is that someone may change their name or author commits
      under different emails and aliases, which would make these
      commits appear as though they came from different persons. The
      file allows you to specify the correct name that should be used
      in place of the author field specified in the commit.
      
      The mailmap file has 4 possible formats used to map old "commit"
      names to new "proper" names:
      
      1. <proper@email.com> <commit@email.com>
      2. Proper Name <commit@email.com>
      3. Proper Name <proper@email.com> <commit@email.com>
      4. Proper Name <proper@email.com> Commit Name <commit@email.com>
      
      Essentially there is a commit email present in each mailmap entry,
      that maps to either an updated name, email, or both. The final
      possible format allows commits authored by a person who used
      both an old name and an old email to map to a new name and email.
      
      To parse the file, we split by spaces and build a name out
      of every element that does not start with "<". Once we find an element
      that does start with "<" we concatenate all the name elements that preceded
      and add that as a parsed name. We then add the email as the first
      parsed email. We repeat the process until the end of the line, or
      a comment is found. We will be left with all parsed names in a list,
      and all parsed emails in a list, with the 0 index being the proper
      values and the 1 index being the commit values (if they were specified
      in the entry).
      
      The commit values are added as the keys to a dict, and with the proper
      fields as the values. The mapname function takes the mapping object and
      the commit author field and attempts to look for a corresponding entry.
      To do so we try (commit name, commit email) first, and if no results are
      returned then (None, commit email) is also looked up. This is due to
      format 4 from above, where someone may have a mailmap entry with both
      name and email, and if they don't it is possible they have an entry that
      uses only the commit email.
      
      Differential Revision: https://phab.mercurial-scm.org/D2904
      2a2ce93e
  3. Mar 30, 2018
  4. Mar 27, 2018
  5. Mar 30, 2018
  6. Mar 21, 2018
  7. Mar 30, 2018
  8. Mar 27, 2018
  9. Feb 09, 2018
  10. Feb 08, 2018
  11. Feb 03, 2018
  12. Feb 09, 2018
    • Pulkit Goyal's avatar
      infinitepush: move the extension to core from fb-hgext · 03ff17a4
      Pulkit Goyal authored
      This patch moves the infinitepush extension from fb-hgext to core. The
      extension is used to store incoming bundles during a push in bundlestore rather
      than applying them to the revlog.
      
      The extension was copied from the repository revision at
      f27f094e91553d3cae5167c0b1c42ae940f888d5 and following changes were made:
      
        * added `from __future__ import absolute_import` where missing
        * fixed module imports to follow the core style
        * minor fixes for test-check-code.t
        * registered the configs
        * adding the testedwith value to match core's convention
        * removed double newlines to make test-check-commit.t happy
        * added one line doc about extension and marked it as experimental
      
      Only one test file test-infinitepush-bundlestore.t is moved to core and
      following changes are made to file:
      
        * remove dependency of library.sh
        * split the tests into two tests i.e. test-infinitepush.t and
          test-infinitepush-bundlestore.t
        * removed testing related to other facebook's extensions pushrebase, inhibit,
          fbamend
      
      library-infinitepush.sh is also copied from fb-hgext from the same revision and
      following changes are made:
      
        * change the path to infinitepush extension as it's in core with this patch
        * removed sql handling from the file as we are not testing that initially
      
      Currently at this revision, test-check-module-imports.t does not pass as there
      is import of a module from fb/hgext in one the of the file which will be removed
      in the next patch.
      
      This extension right now has a lot of things which we don't require in core like
      `--to`, `--create` flags to `hg bookmark`, logic related to remotenames
      extension and another facebook's extensions, custom bundle2parts which can be
      prevented by using bookmarks bundle part and also logic related to sql store
      which is probably we don't want initially.
      
      The next patches in this series will remove all the unwanted and unrequired
      things from the extension and will make this a nice one.
      
      The end goal is to have a very lighweight extension with no or very less
      wrapping on the client side.
      
      Differential Revision: https://phab.mercurial-scm.org/D2096
      03ff17a4
  13. Mar 30, 2018
  14. Mar 03, 2018
  15. Mar 30, 2018
  16. Mar 22, 2018
    • Gregory Szorc's avatar
      repository: define interface for local repositories · 0dfb5672
      Gregory Szorc authored
      Per discussions on the mailing list and at the 4.4 and 4.6 sprints,
      we want to start defining interfaces for local repository primitives
      so that we a) have a better idea of what the formal interface for
      various types is b) can more easily introduce alternate implementations
      of various components (e.g. in Rust).
      
      We have previously implemented interfaces that declare the peer and
      wire protocol APIs using the abc module.
      
      This commit introduces a monolithic interface for the localrepository
      class. It uses zope.interface - not abc - for defining and declaring
      the interface.
      
      The newly defined "completelocalrepository" interface is objectively
      horrible. It is based on what is actually in localrepository and
      doesn't represent a reasonable interface definition IMO. There's lots
      of... unwanted garbage in the interface. In other words, it reflects
      the horrible state of the localrepository "god object." But this is
      fine: a goal of this commit is to get the interface defined so that
      we have an interface. Future commits can refactor the interface
      into sub-interfaces, remove unwanted public attributes, etc.
      
      I attempted to define reasonable docstrings for the various interface
      members. But there are so many of them and I didn't know what some are
      used for. So I was lazy in a number of places and didn't write
      docstrings or detailed usage docs.
      
      Also, the members of the interface are defined in the order they are
      declared in localrepo.py. This revealed that the grouping of things
      in localrepo.py is... odd.
      
      The localrepository class now declares that it implements our newly
      defined interface. Unlike abc, zope.interface doesn't check interface
      conformance at type creation time (abc uses __metaclass__ magic to
      validate interface conformance when a type is created - usually at
      module import time). It does provide some functions for validating
      class and object conformance with declared interfaces. We add these
      checks to test-check-interfaces.py. We /could/ validate at run-time.
      But we hold off for now. (I'm a bit scared of doing that because of
      the various ways extensions monkeypatch repo instances.)
      
      After this commit, test-check-interfaces.py will fail if the set of
      public attributes on the localrepository class or instances change
      without corresponding updates to the interface. This is by design.
      
      Differential Revision: https://phab.mercurial-scm.org/D2933
      0dfb5672
    • Gregory Szorc's avatar
      setup: register zope.interface packages and compile C extension · 922b3fae
      Gregory Szorc authored
      With this change, we should be able to use zope.interface in core!
      
      Differential Revision: https://phab.mercurial-scm.org/D2932
      922b3fae
    • Gregory Szorc's avatar
      thirdparty: allow zope.interface.advice to be lazily imported · 49630e75
      Gregory Szorc authored
      The symbol from this module is only used in functions. Let's access
      that symbol through its imported module so importing
      zope.interface.advice can be lazy.
      
      Differential Revision: https://phab.mercurial-scm.org/D2931
      49630e75
    • Gregory Szorc's avatar
      thirdparty: port zope.interface to relative imports · 68ee6182
      Gregory Szorc authored
      By using relative imports, we're guaranteed to get modules
      vendored with Mercurial rather than other random modules
      that might be in sys.path.
      
      My editor strips trailing whitespace on save. So some minor
      source code cleanup was also performed as part of this commit.
      
      # no-check-commit because some modified lines have double newlines
      
      Differential Revision: https://phab.mercurial-scm.org/D2930
      68ee6182
    • Gregory Szorc's avatar
      thirdparty: don't make zope a namespace package · 338367d4
      Gregory Szorc authored
      There are a gazillion zope.* packages in the wild. So zope/__init__.py
      needs to be a namespace package. But in Mercurial, we have 1 zope
      package. And even if we had multiple packages, they'd all be in
      thirdparty/zope/. So we don't need a namespace package.
      
      Differential Revision: https://phab.mercurial-scm.org/D2929
      338367d4
    • Gregory Szorc's avatar
      thirdparty: vendor zope.interface 4.4.3 · 943d77fc
      Gregory Szorc authored
      I've been trying to formalize interfaces for various components
      of Mercurial. So far, we've been using the "abc" package. This
      package is "good enough" for a lot of tasks. But it quickly
      falls over. For example, if you declare an @abc.abstractproperty,
      you must implement that attribute with a @property or the class
      compile time checking performed by abc will complain. This often
      forces you to implement dumb @property wrappers to return a
      _ prefixed attribute of the sane name. That's ugly.
      
      I've also wanted to implement automated checking that classes
      conform to various interfaces and don't expose other "public"
      attributes.
      
      After doing a bit of research and asking around, the general
      consensus seems to be that zope.interface is the best package for
      doing interface-based programming in Python. It has built-in
      support for verifying classes and objects conform to interfaces.
      It allows an interface's properties to be defined during __init__.
      There's even an "adapter registry" that allow you to register
      interfaces and look up which classes implement them. That could
      potentially be useful for places where our custom registry.py
      modules currently facilitates central registrations, but at a
      type level. Imagine extensions providing alternate implementations
      of things like the local repository interface to allow opening
      repositories with custom requirements.
      
      Anyway, this commit vendors zope.interface 4.4.3. The contents of
      the source tarball have been copied into mercurial/thirdparty/zope/
      without modifications.
      
      Test modules have been removed because they are not interesting
      to us.
      
      The LICENSE.txt file has been copied so it lives next to the
      source.
      
      The Python modules don't use relative imports. zope/__init__.py
      defines a namespace package. So we'll need to modify the source
      code before this package is usable inside Mercurial. This will
      be done in subsequent commits.
      
      # no-check-commit for various style failures
      
      Differential Revision: https://phab.mercurial-scm.org/D2928
      943d77fc
  17. Mar 30, 2018
    • Martin von Zweigbergk's avatar
      context: set repo property in basectx · fbe34945
      Martin von Zweigbergk authored
      It seems like a good practice to call the super constructor. Let's
      start by passing the repo along to basectx so it can assign it to a
      private attribute. We should perhaps pass the rev and node along as
      well, but that requires more work before it can be done.
      
      Differential Revision: https://phab.mercurial-scm.org/D2970
      fbe34945
    • Martin von Zweigbergk's avatar
      context: move reuse of context object to repo.__getitem__ (API) · bb47dc2f
      Martin von Zweigbergk authored
      As an example of how weird the basectx.__new__ is: whenever you create
      a workingctx, basectx.__new__ gets called first. Since our __new__ has
      a "changeid" argument as second parameter, when create the
      workingctx(repo, text="blah"), the text gets bound to
      "changeid". Since a string isn't a basectx, our __new__ ends up not
      doing anything funny, but that's still very confusing code.
      
      Another case is metadataonlyctx.__new__(), which I think exists in
      order to prevent metadataonlyctx.__init__'s third argument
      (originalctx) from being interpreted as a changeid in
      basectx.__new__(), thereby getting reused.
      
      Let's move this to repo.__getitem__ instead, where it will be pretty
      obvious what the code does.
      
      After this patch, changectx(ctx) will be an error (it will fail when
      trying to see if it's a 20-byte string).
      
      Differential Revision: https://phab.mercurial-scm.org/D2969
      bb47dc2f
    • Martin von Zweigbergk's avatar
      memctx: create parent contexts using "repo[p]" syntax · 05ff1a15
      Martin von Zweigbergk authored
      I want to reduce dependence on basectx.__new__() and move that code
      over to repo.__getitem__().
      
      Differential Revision: https://phab.mercurial-scm.org/D2968
      05ff1a15
    • Martin von Zweigbergk's avatar
      context: avoid using a context object as a changeid · daef13da
      Martin von Zweigbergk authored
      I find it misleading to pass changeid=changectx. It currently works to
      do that because there's weird (IMO) handling of it in
      basectx.__new__. I'm planning on removing that code. Passing changeid
      as "changeid" and context as "context" makes it more readable.
      
      Note that the documentation of filectx.__init__ doesn't even seem to
      be aware that a changeid can be a context ("changeset revision, node,
      or tag").
      
      Differential Revision: https://phab.mercurial-scm.org/D2967
      daef13da
Loading