fileset: add kind:pat operator ":" isn't taken as a symbol character but an infix operator so we can write e.g. "path:'foo bar'" as well as "'path:foo bar'". An invalid pattern kind is rejected in the former form as we know a kind is specified explicitly. The binding strength is copied from "x:y" range operator of revset. Perhaps it can be adjusted later if we want to parse "foo:bar()" as "(foo:bar)()", not "foo:(bar())". We can also add "kind:" postfix operator if we want. One possible confusion is that the scope of the leading "set:" vs "kind:pat" operator. The former is consumed by a matcher so applies to the whole fileset expression: $ hg files 'set:foo() or kind:bar or baz' ^^^^^^^^^^^^^^^^^^^^^^^^ Whereas the scope of kind:pat operator is narrow: $ hg files 'set:foo() or kind:bar or baz' ^^^

minifileset: unify handling of symbol and string patterns They must be identical for fileset compatibility.

fileset: move import of match module to top Actually there was no circular import issue.

revlog: group delta computation methods under _deltacomputer object Extracting these methods from revlog will allow changing the implementation of the deltacomputer, by providing this interface: __init__(self, revlog) - constructor that initialize the object from a given revlog buildtext(self, revinfo, fh) - builds the fulltext version of a revision from a _revisioninfo object and the file handle to the .d (or .i for inline mode) file. finddeltainfo(self, revinfo, fh) - find a revision in the revlog against which it is acceptable to build a delta, and build the corresponding _deltainfo. It should now be easier to write an experimental feature that would replace _deltacomputer by another object, for example one that would know how to parallelize the delta computation in order to quicken the storage of multiple revisions.

revlog: refactor out _finddeltainfo from _addrevision Splicing the code into smaller chunks should help understanding it, and eventually override some parts in experimental branches to try optimization.

localrepo: micro-optimize __len__() to bypass repoview Since len(changelog) isn't overridden, we don't have to validate a cache of unfiltered changelog. $ python -m timeit -n 10000 \ -s 'from mercurial import hg, ui; repo = hg.repository(ui.ui());' \ 'len(repo)' orig) 10000 loops, best of 3: 32.1 usec per loop new) 10000 loops, best of 3: 1.79 usec per loop Spotted by Jordi Gutiérrez Hermoso.

lfs: defer registering the pre-push hook until blobs are committed The hook searches outgoing commits for blobs, and uploads them before letting the push occur. No reason to search for that which isn't there.

lfs: dump the full response on httperror in debug mode This was immensely helpful in diagnosing the 500: Internal Server Error when using workers to upload. It's a nasty wall of html, so we really can't do anything else with it.

lfs: default the User-Agent header for blob transfers to 'git-lfs' The custom User-Agent for blob transfers was added in e7bb5fc4570c. Now I've hit another incompatibility with a server wanting the string to start with 'git' or 'git-lfs' [1]. I don't feel strongly about this either way, but a Wireshark trace of git shows that when the Batch API is hit, the User-Agent is 'git-lfs/2.3.4'. So this would probably ensure maximum interoperability. This still leaves the experimental knob in, just in case. [1] https://bitbucket.org/sdorra/scm-manager/src/095a027178888bc2b819aebfae3d2c192c858030/scm-plugins/scm-git-plugin/src/main/java/sonia/scm/web/GitUserAgentProvider.java?at=default&fileviewer=file-view-default#GitUserAgentProvider.java-117

lfs: default to not using workers for upload/download I ran into truncated uploads with this defaulting to on. Wojciech Lis diagnosed it as creating keepalive connections prior to forking, and illegally multiplexing the same connection. [1] I didn't notice a problem with the couple of downloads I tried, but disabled both for simplicity and safety. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-January/109916.html