- Mar 31, 2018
-
-
Matt Harbison authored
-
- Mar 19, 2018
-
-
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
-
- Mar 30, 2018
-
-
Kyle Lippincott authored
Differential Revision: https://phab.mercurial-scm.org/D2976
-
Gregory Szorc authored
Previously, we tried to import a module and handle the ImportError. Our lazy module importer doesn't verify the module exists and returns a dummy object representing the module. Only once we attempt to load a symbol in the module does the ImportError get raises. This means that simple imports inside `try..except ImportError` don't detect missing modules. This commit changes imports in zope.interface to access symbols, thus forcing module load and triggering ImportError. This fixes zope.interface for pure builds. Differential Revision: https://phab.mercurial-scm.org/D2980
-
Danny Hooper authored
Differential Revision: https://phab.mercurial-scm.org/D2977
-
- Mar 27, 2018
-
-
Pulkit Goyal authored
This patch introduces a new config option for server `infinitepush.pushtobundlestore` which if sets to True, the server will route each incoming push to the bundlestore and store all the parts i.e. changegroups, phases, obsmarkers in the bundlestore and won't be applied to the revlog. This config option does not need any client side wrapping and does not need any custom bundle2 part or stream level parameter to decide where the push should go. This is very useful for Mozilla CI use case where they have a central server that recieves pushes to trigger code-reviews, trigger a test run of CI, run static analysis etc. The server using the new config option can stash standalone bundles to the bundlestore and server can get access to individual revisions on demand. A new test file which has related tests are added for the config option. Differential Revision: https://phab.mercurial-scm.org/D2958
-
Pulkit Goyal authored
This patch adds dirty logic to check whether we are processing `hg unbundle` instead of an `hg incoming` to prevent the wrapping of bundle2.processparts function. Differential Revision: https://phab.mercurial-scm.org/D2957
-
Pulkit Goyal authored
Recently in core, util.py is splitted into various modules in mercurial/utils/. Differential Revision: https://phab.mercurial-scm.org/D2956
-
- Mar 30, 2018
-
-
Pulkit Goyal authored
Differential Revision: https://phab.mercurial-scm.org/D2955
-
- Mar 21, 2018
-
-
Pulkit Goyal authored
The extension wraps update command to client side to add functionality to pull and checkout to a revision if it does not present locally. There is a twist to that, only changesets which can resolve to remotenames can be pulled using this. Differential Revision: https://phab.mercurial-scm.org/D2954
-
- Mar 30, 2018
-
-
Pulkit Goyal authored
This patch drops infinitepushcommands.py and the tests which were related to the command `debugfillinfinitepushmetadata` introduced in the commit. The patch also drops a config option which was related to debuginfinitepushmetadata command. Differential Revision: https://phab.mercurial-scm.org/D2953
-
- Mar 27, 2018
-
-
Pulkit Goyal authored
This patch deletes the config option infinitepush.fillmetadatabranchpattern which if set to true sets a background process which will save metadata in infinitepush index. This series is meant to have a state where we can use it for CI purposes. Differential Revision: https://phab.mercurial-scm.org/D2952
-
- Feb 09, 2018
-
-
Pulkit Goyal authored
The extension added a `--to` flag to specify the bookmark to which revs should be pushed. This patch deletes that flag and instead uses the `-B` flag. After this patch, bookmark passed as `-B` is parsed and if it matches the infinitepush bookmark pattern, we consider that push as infinitepush. This is still not the best of what we can do. Later patches in the series will drop the use of `-B` flag and will instead handle things at bookmark bundle2 part. Plugging these logic to bookmark bundle2 part will also get rid of the scratchbranchparttype bundle2 part. Differential Revision: https://phab.mercurial-scm.org/D2108
-
Pulkit Goyal authored
The extension added a `--create` flag for creating a new bookmark on the bundlestore. This patch changes the bahviour to create a bookmark if it does not exists and removes the requirement of the `--create` and then drop the logic around the `--create` flag. Tests are changed to drop the usage of `--create` flag. Differential Revision: https://phab.mercurial-scm.org/D2107
-
Pulkit Goyal authored
treemanifest is another facebook's extension which is not in core. Let's drop the logic related to infinitepush extension which is now ported to core. Differential Revision: https://phab.mercurial-scm.org/D2106
-
Pulkit Goyal authored
The remotenames extension has --to, --create. --allow-anon flags which won't be ported to core. This patch drops the hack which fixes the interaction with remotenames-ext during push. In upcoming patches, --to and --create extensions will be removed from infinitepush also. Differential Revision: https://phab.mercurial-scm.org/D2105
-
Pulkit Goyal authored
This is something which is internal to Facebook and we don't want in core. Differential Revision: https://phab.mercurial-scm.org/D2104
-
Pulkit Goyal authored
The extension adds these two flags to list remote bookmarks using the `hg bookmark` command. These are not required in core currently and needs some discussion before getting them in, so let's drop them for now. This makes us deleting the wrapping of `hg bookmark` command on client side. The end goal here is to have minimal or no wrapping at client side. Differential Revision: https://phab.mercurial-scm.org/D2103
-
- Feb 08, 2018
-
-
Pulkit Goyal authored
The scratchbookmarksparttype bundle2 part was used in backupcommands.py which we deleted in an earlier changeset. We don't need this part anymore. Moreover we now have bookmarks bundle2 part in core which we can use. This patch also drops the related encoding and decoding functions. Differential Revision: https://phab.mercurial-scm.org/D2102
-
Pulkit Goyal authored
This wrapping around bundle2._addpartsfromopts() was added by me while hacking on an alternate way to mark a push as infinitepush or not. However the wrapping is wrong as the push command does not go through the code path which was wrapped on the client side. Differential Revision: https://phab.mercurial-scm.org/D2101
-
Pulkit Goyal authored
pushrebase is another Facebook extension which does not live in core yet. So let's remove the logic which make sures infinitepush part is moved before the pushrebase one. Differential Revision: https://phab.mercurial-scm.org/D2100
-
Pulkit Goyal authored
The remotenames extension which circumvents the default push implementation lives outside the core, so let's delete logic related to loading of extension on the basis of remotenames ext. Differential Revision: https://phab.mercurial-scm.org/D2099
-
- Feb 03, 2018
-
-
Pulkit Goyal authored
The inhibit extension lives in hg-experimental and is not a core extension. Differential Revision: https://phab.mercurial-scm.org/D2098
-
Pulkit Goyal authored
This file contains command pushbackup and pullbackup which are used to store things to infinitepush. This is an advanced functionality which we don't require as of now. Also this uses shareutil.py from fb-hgext/ which is not there in core. Therefore this patch deletes the file and the config option which belongs to the backup thing. If we need this functionality in future, we can always move this file back. Differential Revision: https://phab.mercurial-scm.org/D2097
-
- Feb 09, 2018
-
-
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
-
- Mar 30, 2018
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D2973
-
Gregory Szorc authored
Differential Revision: https://phab.mercurial-scm.org/D2975
-
Gregory Szorc authored
"blacklist" is racially charged. Let's rename it to something that isn't. Differential Revision: https://phab.mercurial-scm.org/D2974
-
- Mar 03, 2018
-
-
Danny Hooper authored
This change implements most of the corresponding proposal as discussed at the 4.4 and 4.6 sprints: https://www.mercurial-scm.org/wiki/AutomaticFormattingPlan This change notably does not include parallel execution of the formatter/fixer tools. It does allow for implementing that without affecting other areas of the code. I believe the test coverage to be good, but this is a hotbed of corner cases. Differential Revision: https://phab.mercurial-scm.org/D2897
-
- Mar 30, 2018
-
-
Gregory Szorc authored
Differential Revision: https://phab.mercurial-scm.org/D2972
-
- Mar 22, 2018
-
-
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
-
Gregory Szorc authored
With this change, we should be able to use zope.interface in core! Differential Revision: https://phab.mercurial-scm.org/D2932
-
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
-
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
-
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
-
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
-
- Mar 30, 2018
-
-
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
-
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
-
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
-
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
-