histedit: pass multiple nodes to strip (BC) Previously, histedit.cleanupnode pass root nodes one by one. Since repair.strip takes multiple nodes and can handle them just fine, pass all strip roots at once. This is BC because the number of strip backup files may change from N to 1.

histedit: remove "name" parameter from cleanupnode functions The "name" parameter is not used any longer so let's remove it.

histedit: remove "should strip" debug message The debug message was not used anywhere. Removed it to make scmutil.cleanupnodes migration easier to reason about.

histedit: move topmost bookmark movement to a separate function histedit treats topmost bookmark movement specially. The rest of the bookmark movement could be handled by scmutil.cleanupnodes. So let's move the special logic out to make the patch easier to review.

histedit: remove moving bookmarks message on verbose (BC) This is more consistent with other commands, like "commit -v" won't show bookmark movement messages. It will make migrating to scmutil.cleanupnodes easier.

test-largefiles-update: conditionalize output instead of tests

test-status-rev: conditionalize output instead of tests

test-mq: conditionalize output instead of tests

test-annotate: conditionalize output instead of tests

test-addremove: conditionalize output instead of tests

test-tools: conditionalize output instead of tests

test-rebase: conditionalize output instead of tests This should help prevent breakage like was fixed in the last patch.

tests: stabilize on Windows I'm not sure if the difference on Windows for test-sparse.t is expected or not. It looks like unless the leading '/' is followed by a drive letter, '/' is resolved to 'C:/MinGW/msys/1.0'. But both cases abort with "not under root" instead of just warning.

revset: make repo.anyrevs accept customized alias override (API) Previously repo.anyrevs only expand aliases in [revsetalias] config. This patch makes it more flexible to accept a customized dict defining aliases without having to couple with ui. revsetlang.expandaliases now has the signature (tree, aliases, warn=None) which is more consistent with templater.expandaliases. revsetlang.py is now free from "ui", which seems to be a good thing.

tests: quote $PYTHON for Windows When unquoted, MSYS sees the colon between the drive letter and path as a Unix path separator and unhelpfully splits on it, feeding only the drive letter as the command. Much chaos ensues. I vaguely remember trying to get the test runner to use /letter/path/to/exe syntax the last time this happened, without success. I doubt a check-code rule would work, since sometimes it is quoted, and sometimes the quotes are escaped.

amend: use scmutil.cleanupnodes (BC) This is marked as BC because the strip backup file name has changed.

rebase: remove "if True" The "if True" block was to make the last patch easier to review. This patch removes "if True" and unindents the block.

rebase: use scmutil.cleanupnodes (issue5606) (BC) This patch migrates rebase to use scmutil.cleanupnodes API. It simplifies the code and makes rebase code reusable inside a transaction. This is a BC because the backup file is no longer strip-backup/*-backup.hg, but strip-backup/*-rebase.hg. The latter looks more reasonable since the directory name is "strip-backup" so there is no need to repeat "backup". I think the backup file name change is probably fine as a BC, since we have changed it before (aa4a1672583e) and didn't get complains. The end result of this series will be a much more consistent and unified backup names: command | old backup file suffix | new backup file suffix ------------------------------------------------------------------- amend | amend-backup.hg | amend.hg histedit | backup.hg (could be 2 files) | histedit.hg (single file) rebase | backup.hg | rebase.hg strip | backup.hg | backup.hg (note: backup files are under .hg/strip-backup) It also fixes issue5606 as a side effect because the new "delayedstrip" code path will carefully examine nodes (safestriproots) to make sure orphaned changesets won't get stripped by accident. Some warning messages are changed to the new "warning: orphaned descendants detected, not stripping HASHES", which provides more information about exactly what changesets are left behind. Another minor behavior change is when there is an obsoleted changeset with a successor in the destination branch, bookmarks pointing to that obsoleted changeset will not be moved. I have commented in test-rebase-obsolete.t explaining why that is more desirable.

scmutil: make cleanupnodes delete divergent bookmarks cleanupnodes takes care of bookmark movement, and bookmark movement could cause bookmark divergent resolution as a side effect. This patch adds such bookmark divergent resolution logic so future rebase migration will be easier. The revset is carefully written to be equivalent to what rebase does today. Although I think it might make sense to remove divergent bookmarks more aggressively, for example: F book@1 | E book@2 | | D book | | | C |/ B book@3 | A When rebase -s C -d E, "book@1" will be removed, "book@3" will be kept, and the end result is: D book | C | F | E book@2 (?) | B book@3 | A The question is should we keep book@2? The current logic keeps it. If we choose not to (makes some sense to me), the "deleterevs" revset could be simplified to "newnode % oldnode". For now, I just make it compatible with the existing behavior. If we want to make the "deleterevs" revset simpler, we can always do it in the future.

scmutil: make cleanupnodes handle filtered node In some valid usecases, the "mapping" received by scmutil.cleanupnodes have filtered nodes. Use unfiltered repo to access them correctly. The added test case will fail with the old cleanupnodes code. This is important to migrate histedit to use the cleanupnodes API.

configitems: add alias support in config Aliases define optional alternatives to existing options. For example the old option ui.user was deprecated and replaced by ui.username. With this mechanism, it's even possible to create an alias to an option in a different section. Add ui.user as alias to ui.username as an example of this concept. The old alternates principle in ui.config is removed as it was used only for this option.

hgweb: use ui._unset to prevent a warning in configitems

dispatch: fix typo suggestion for disabled extension If the matching command lives in an in-tree extension (which is all we scan for), and the user has disabled that extension with "extensions.<name>=!", we were not finding it, because the path in _disabledextensions was the empty string. If the user had set "extensions.<name>=!<valid path>" it would work, so it seems like just a mistake that it didn't work.

tests: add tests for typoed commands This includes one test showing how disabling a command with e.g. "extensions.rebase=!" results in the command not being suggested. We'll fix that next.

sparse: inline signature cache clearing It is a trivial one-liner. No need to have a separate function.

sparse: move working directory refreshing into core This is a pretty straightforward move of the code. I converted the "force" argument to a keyword argument. Like other recent changes, this code is tightly coupled with working directory update code in merge.py. I suspect the code will become more tightly coupled over time, possibly even moved to merge.py. For now, let's get the code in core.

sparse: refactor update actions filtering and call from core merge.calculateupdates() now filters the update actions through sparse by default. The filtering no-ops if sparse isn't enabled or no sparse config is defined. The function has been refactored to behave more like a filter instead of a wrapper of merge.calculateupdates(). We should arguably take sparse into account earlier in merge.calculateupdates(). This patch preserves the old behavior of applying sparse at the end of update calculation, which is the simplest and safest approach.

sparse: move update action filtering into core This is a relatively straight port of the function. It is pretty large. So refactoring will be postponed to a subsequent commit.

sparse: move pruning of temporary includes into core This was our last method on the custom repo type, meaning we could remove that custom type and inline the 2 lines of code into reposetup(). As part of the move, instead of wrapping merge.update() from the sparse extension, we inline the function call. The ported function now no-ops if sparse isn't enabled, making it safe to always call. The call site in update() may not be the most appropriate. But it matches the previous behavior, which is the safest thing to do. It can be improved later.

sparse: move function for resolving sparse matcher into core As part of the move, the function arguments changed so revs are passed as a list instead of *args. This allows us to use keyword arguments properly. Since the plan is to integrate sparse into core and have it enabled by default, we need to prepare for a sparse matcher to always be obtained and operated on. As part of the move, we inserted code that returns an always matcher if sparse isn't enabled. Some callers in the sparse extension take this into account and conditionally perform matching depending on whether the special always matcher is seen. I /think/ this may have sped up some operations where the extension is installed but no sparse config is activated. One thing I'm ensure of in this code is whether os.path.dirname() is semantically correct. os.posixpath.dirname() (which is exported as pathutil.dirname) might be a better choise because all patterns should be using posix directory separators (/) instead of Windows (\). There's an inline comment that implies Windows was tested. So hopefully it won't be a problem. We can improve this in a follow-up. I've added a TODO to track it.

match: move matchers from sparse into core The sparse extension contains some matcher types that are generic and can exist in core. As part of the move, the classes now inherit from basematcher. always(), files(), and isexact() have been dropped because they match the default implementations in basematcher.

sparse: clean up config signature code Before, 0 was being used as the default signature value and we cast the int to a string. We also handled I/O exceptions manually. The new code uses cfs.tryread() so we always feed data into the hasher. The empty string does hash and and should be suitable for input into a cache key. The changes made the code simple enough that the separate checksum function could be inlined.

sparse: move config signature logic into core This is a pretty straightforward port. It will be cleaned up in a subsequent commit.

sparse: remove custom hash matcher With the recent change to always use repr(), this function was functionally identical to the version in fsmonitor it was replacing. So remove it.

sparse: override __repr__ in matchers sparse.py in FB's hg-experimental repo switched to using __repr__ for non-sparse matchers soon after hg core started overriding __repr__ in the matchers in match.py (because the core matchers also stopped having "includepat" and other attributes that sparse used to depend on). Let's finish that migration by implementing __repr__ in the sparse matchers as well. That also lets us remove the special handling of them in _hashmatcher().

tests: fix reference to undefined variable The delaypush() function had a reference to "repo" that was clearly supposed to be "pushop.repo". Instead of just fixing that, let's extract "pushop.repo.ui" to a variable, since that's the only piece of the repo that's needed in the function. I have not looked into why I saw a different result in the test to start with, but that's for another patch anyway.

shelve: don't reimplement mergestate.unresolved()

summary: don't reimplment mergestate.unresolved()

mergestate: implement unresolvedcount() in terms of unresolved() This simplifies the method slightly. It does create a full list of paths while doing so, but it's not a lot of data anyway (besides, I would think references to strings are no larger than (references to?) True).

mergestate: make unresolved() use iteritems() mergestate.unresolved() is a generator, so it seems better for it to rely on iteritems() than items(), although it also seems unlikely for it to make a noticeable difference.

changegroup: don't fail on empty changegroup (API) I don't know why applying an empty changegroup should be an error. It seems harmless. I suspect the check was there to find code that creates empty changegroups just because that would be wasteful. Let's use develwarn() for that instead, so we catch any such cases that run with our test runner, but we still allow others to generate empty changegroups if they want to. We have run into this check at Google once or twice and had to work around it, but I'm changing this not so much because of that, but because it seems like it shouldn't be an error. I also changed the message slightly to be more modern ("changelog group" -> "changegroup") and more generic ("received" -> "applied").

changegroup: remove option to allow empty changegroup (API) No caller sets the "emptyok" option, so let's remove it.

strip: don't allow empty changegroup in bundle1 Applying an empty changegroup has been an error since the beginning. The only exception was strip, which would allow to apply an empty changegroup from the temporary bundle. However, the emptyok=True option was only set for bundle1 bundles. In other words, temporary bundle2 bundles would fail if they were empty. Bundle2 has now been used enough that it seems safe to say that we simply don't create bundle2 bundles with empty changegroups. That also suggests that we never create bundle1 bundles with empty changegroups (i.e. empty bundle1 bundles, since bundle1 is just a changegroup), because, AFAICT, the code leading up to the application of the bundle is the same for bundle1 and bundle2. Therefore, let's stop passing emptyok=True, so we more clearly get the same behavior for bundle1 and bundle2.

match: minor cleanups to patternmatcher and includematcher The "patterns"/"include" in "patternspat"/"includepat" is redundant, so drop it. Also a "_" prefix since it's "private". Inline the "pm"/"im" variables.

py3: fix test-diff-newlines.t to be compatible with py3

sparse: move some temporary includes functions into core Functions for reading and writing the tempsparse file have been moved. prunetemporaryincludes() will be moved separately because it is non-trivial.

sparse: move config file writing into core The code was refactored during the move to be more procedural instead of using string formatting. This has the benefit of not writing empty sections, which changed tests.

localrepo: add sparse caches The sparse extension maintains caches for the sparse files to a signature and a signature to a matcher. This allows the sparse matchers to be resolved quickly, which is apparently something that can occur in loops. This patch ports the sparse caches to the localrepo class pretty much as-is. There is potentially room to improve the caching mechanism. But that can be done as a follow-up. The default invalidatecaches() now clears the relevant sparse cache. invalidatesignaturecache() has been moved to sparse.py.

sparse: move active profiles function into core Also includes some light formatting changes.

sparse: move resolving of sparse patterns for rev into core This method is reasonably well-contained and simple to move. As part of the move, some light formatting was performed. A "working copy" reference in an error message was changed to "working directory." The biggest change was to _refreshoncommit() in sparse.py. It was previously checking for the existence of an attribute on the repo instance. Since the moved function now returns empty data if sparse isn't enabled, we unconditionally call the new function. However, we do have to protect another method call in that function. This will all be unhacked eventually.

sparse: variable to track if sparse is enabled Currently, the sparse extension sniffs repo instances for attributes defined by the sparse extension to determine if sparse is enabled. As we move code away from repo instances, these checks will be a bit more brittle. We introduce a module-level variable to track whether sparse is enabled as a temporary workaround.

sparse: move profile reading into core One more step towards weaning off methods on repo instances and moving code to core. While this function is only used once and is simple, it needs to exist on its own so Facebook can monkeypatch it to enable simplecache integration.

sparse: move config parsing into core This patch marks the beginning of moving code from the sparse extension into core. The goal is to move as much of the functionality as possible into core, where it will be an experimental feature. The extension will likely continue to exist to enable the feature and provide UI elements. As part of the move, the repo method was converted to a module function. It doesn't need to exist on repos. An error message was also updated to reflect that an error isn't necessarily from the .hg/sparse file. The API should be updated later to pass in a filename so the error can be more descriptive. Copyright of the added file was copied from the sparse extension.

sparse: use vfs.tryread() vfs.exists() followed by a file read is an anti-pattern because it incurs an extra stat() to test for file presence. vfs.tryread() returns empty string on missing file and avoids the stat().

sparse: refactor sparsechecksum() This was relying on garbage collection to close the opened file, which is a bug. Both callers simply called into self.vfs to resolve the path. So refactor to use the vfs layer. While we're here, rename the method to reflect it is internal and to break anyone relying on the old behavior.

sparse: document config file format This was previously undocumented. Seems useful to have.

sparse: rename command to debugsparse Sparse checkout is still highly experimental and not protected by BC guarantees yet. We also haven't had a discussion on the UX. To discourage use, we rename the sparse command to debugsparse.

sparse: remove reference to simplecache This is a 3rd party extension authored by Facebook. References in core are not appropriate. It will be possible to restore this code/optimization via monkeypatching. So Facebook won't lose any functionality. The removed code is important for performance. So add a comment tracking it.

sparse: remove reference to hgwatchman This is a legacy extension. Now that the extension is in core, we only need to support what's in core, which is fsmonitor.

sparse: expand module docstring Clarify lack of BC guarantees. And say a bit more about the extension.

sparse: vendor Facebook-developed extension Facebook has developed an extension to enable "sparse" checkouts - a working directory with a subset of files. This feature is a critical component in enabling repositories to scale to infinite number of files while retaining reasonable performance. It's worth noting that sparse checkout is only one possible solution to this problem: another is virtual filesystems that realize files on first access. But given that virtual filesystems may not be accessible to all users, sparse checkout is necessary as a fallback. Per mailing list discussion at https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-March/095868.html we want to add sparse checkout to the Mercurial distribution via roughly the following mechanism: 1. Vendor extension as-is with minimal modifications (this patch) 2. Refactor extension so it is more clearly experimental and inline with Mercurial practices 3. Move code from extension into core where possible 4. Drop experimental labeling and/or move feature into core after sign-off from narrow clone feature owners This commit essentially copies the sparse extension and tests from revision 71e0a2aeca92a4078fe1b8c76e32c88ff1929737 of the https://bitbucket.org/facebook/hg-experimental repository. A list of modifications made as part of vendoring is as follows: * "EXPERIMENTAL" added to module docstring * Imports were changed to match Mercurial style conventions * "testedwith" value was updated to core Mercurial special value and comment boilerplate was inserted * A "clone_sparse" function was renamed to "clonesparse" to appease the style checker * Paths to the sparse extension in tests reflect built-in location * test-sparse-extensions.t was renamed to test-sparse-fsmonitor.t and references to "simplecache" were removed. The test always skips because it isn't trivial to run it given the way we currently run fsmonitor tests * A double empty line was removed from test-sparse-profiles.t There are aspects of the added code that are obviously not ideal. The goal is to make a minimal number of modifications as part of the vendoring to make it easier to track changes from the original implementation. Refactoring will occur in subsequent patches.

contrib: widen "direct use of `python`" net again I think I've now caught all of them. Differential Revision: https://phab.mercurial-scm.org/D15

tests: clean up a newly-introduced instance of `python` Differential Revision: https://phab.mercurial-scm.org/D16

tests: clean up even more direct `python` calls with $PYTHON This time ones that are prefixed with =, ", ', or `. This appears to be the last of them. Differential Revision: https://phab.mercurial-scm.org/D14

contrib: widen the "don't use `python`" net a little I'm still cleaning this up, but it's easier to do in bite-size chunks like this than all at once. The negative lookahead avoids one false positive category from some output related to finding Subversion bindings. Differential Revision: https://phab.mercurial-scm.org/D13

followlines: join merge parents line ranges in blockdescendants() (issue5595) In blockdescendants(), we had an assertion when line range of a merge changeset was not consistent depending on which parent was considered for computation. For instance, this might occur when file content (in lookup range) is significantly different between parent branches of the merge as demonstrated in added tests (where we almost completely rewrite the "baz" file while also introducing similarities with its content in the other branch we later merge to). Now, in such case, we combine line ranges from all parents by storing the envelope of both line ranges. This is conservative (the line range is extended, possibly unnecessarily) but at least this should avoid missing descendants with changes in a range that would fall in that of one parent but not in another one (the case of "baz: narrow change (2->2+)" changeset in tests).

workingfilectx: add exists, lexists Switch the lone call in merge.py to use it. As with past refactors, the goal is to make wctx hot-swappable with an in-memory context in the future. This change should be a no-op today.

vfs: add explanation about cost of checkambig=True in corner case

vfs: replace avoiding ambiguity in abstractvfs.rename with _avoidambig This centralizes common logic to forcibly avoid file stat ambiguity into _avoidambig(), which was introduced by previous patch.

vfs: copy if EPERM to avoid file stat ambiguity forcibly at closing Now, files (to be truncated) are opened with checkambig=True, only if localrepository caches it. Therefore, straightforward "copy if EPERM" is always reasonable to avoid file stat ambiguity at closing. This patch makes checkambigatclosing close wrapper copy the target file, and advance mtime on it after renaming, if EPERM. This can avoid file stat ambiguity, even if the target file is owned by another (see issue5418 and issue5584 for detail). This patch factors main logic out instead of changing checkambigatclosing._checkambig() directly, in order to reuse it.

transaction: apply checkambig=True only on limited files for similarity Now, transaction can determine whether avoidance of file stat ambiguity is needed for each files, by blacklist "checkambigfiles". For similarity to truncation in _playback(), this patch apply checkambig=True only on limited files in code paths below. - restoring files by util.copyfile(), in _playback() (checkambigfiles itself is examined at first, because it as a keyword argument might be None) - writing files at finalization of transaction, in _generatefiles() This patch reduces cost of checking stat at writing out and restoring files, which aren't filecache-ed.

transaction: avoid file stat ambiguity only for files in blacklist Advancing mtime by os.utime() fails for EPERM, if the target file is owned by another. bff5ccbe5ead and related changes made some code paths give advancing mtime up in such case, to fix issue5418. This causes file stat ambiguity (again), if it is owned by another. https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan To avoid file stat ambiguity in such case, especially for .hg/dirstate, ed66ec39933f made vfs.rename() copy the target file, and advance mtime of renamed one again, if EPERM (see issue5584 for detail). But straightforward "copy if EPERM" isn't reasonable for truncation of append-only files at rollbacking, because rollbacking might cost much for truncation of many filelogs, even though filelogs aren't filecache-ed. Therefore, this patch introduces blacklist "checkambigfiles", and avoids file stat ambiguity only for files specified in this blacklist. This patch consists of two parts below, which should be applied at once in order to avoid regression. - specify 'checkambig=True' at vfs.open(mode='a') in _playback() according to checkambigfiles - invoke _playback() with checkambigfiles - add transaction.__init__() checkambigfiles argument, for _abort() - make localrepo instantiate transaction with _cachedfiles - add rollback() checkambigfiles argument, for "hg rollback/recover" - make localrepo invoke rollback() with _cachedfiles After this patch, straightforward "copy if EPERM" will be reasonable at closing the file opened with checkambig=True, because this policy is applied only on files, which are listed in blacklist "checkambigfiles".

localrepo: store path and vfs location of cached properties This information is used to make transaction handle these files specially, in order to avoid file stat ambiguity of them. Gathering information about cached files via annotation classes can avoid overlooking properties newly introduced in the future.

template: add successors template Add a 'successorssets' template that returns the list of all closest known sucessorssets for a changectx. The elements of the list are changesets. The "closest successors" are the first locally known revisions encountered while, walking successors markers. It uses successorsets previously modified to support the closest argument. This logic respect repository filtering. So hidden revision will be skipped by this logic unless --hidden is specified. Since we only display the visible predecessors, this template will not display anything in most case. It makes a good candidate for inclusion in the default log output. I updated the test-obsmarker-template.t test file introduced with the predecessors template to test successorssets template.

template: add tests for more complex cases We add new tests for improving the coverage of existing obs-markers related template (predecessors) and the new one we are introducing (successorssets).

obsolete: closest divergent support Add a closest argument to successorssets changing the definition of latest successors. With "closest=false" (current behavior), latest successors are "leafs" on the obsmarker graph. They don't have any successor and are known locally. With "closest=true", latest successors are the closest locally-known changesets that are visible in the repository or repoview. Closest successors can be then obsolete, orphan. This will be used in a later patch to show the closest successor of changesets with the successorssets template.

obsolete: pass cache argument of successors set explicitly We plan to add a new argument to successorsets. But first we need to update all callers to pass cache argument explicitly to avoid arguments confusion.

obsolete: small doc update for 'successorssets' Clarify successorssets documentation before we start updating the main function. This patch serie will introduce the successorssets template, the opposite of predecessor templates. Successors will use successorssets function and requires some improvement so before doing that, we clean up successorssets a bit.

phabricator: do not read a same revision twice It's possible to set up non-linear dependencies in Phabricator like: o D4 |\ | o D3 | | o | D2 |/ o D1 The old `phabread` code will print D1 twice. This patch adds de-duplication to prevent that. Test Plan: Construct the above dependencies in a Phabricator test instance and make sure the old code prints D1 twice while the new code won't.

patch: make parsepatch optionally trim context lines Previously there is a suspicious `if False and delta > 0` which dates back to the beginning of hgext/record.py (b2607267236d). The "trimming context lines" feature could be useful (and is used by the next patch). So let's enable it. This patch adds a new `maxcontext` parameter to `recordhunk` and `parsepatch`, changing the `if False` condition to respect it. The old `trimcontext` implementation is also wrong - it does not update `toline` correctly and it does not do the right thing for `before` context. A doctest was added to guard us from making a similar mistake again. Since `maxcontext` is set to `None` (unlimited), there is no behavior change.

phabricator: try to fetch differential revisions in batch Previously, we read Differential Revisions one by one by calling `differential.query`. Fetching them one by one is suboptimal. Unfortunately, there is no Conduit API that allows us to get a stack of diffids using a single API call. This patch tries to be smarter using a simple heuristic: when fetching D59 as a stack, previous IDs like D51, D52, D53, ..., D58 are likely belonging to a same stack so just fetch them as well. Since `differential.query` only returns cheap metadata without expensive diff content, it shouldn't be a big problem for the server. Using a test Phabricator instance, this patch reduces `phabread` reading a 10 patch stack from about 13 to 30 seconds to 8 seconds.

phabricator: avoid calling differential.getcommitmessage Previously, we call differential.getcommitmessage API to get commit messages. Now we read that from "Differential Revision" object fetched via "differential.query" API. This removes one API call per patch.

phabricator: rework phabread to reduce memory usage and round-trips This patch reworked phabread a bit so it fetches the lightweight "Differential Revision" metadata for a stack first. Then read other data. This allows the code to: a) send 1 request to get all `hg:meta` data instead of N requests b) patches are read in desired order, no need to buffer the output "b)" reduces the memory usage from O(N^2) to O(N) since we no longer keep old patch contents in memory. The above `N` means the number of patches in the stack.

phabricator: abort if phabsend gets empty revs Previously we didn't abort. Now we abort if revs is empty. This is consistent with "hg export" behavior. Maybe "return 1" is also a reasonable behavior, but that's inconsistent with the existing "hg export".

phabricator: do not upload new diff if nothing changes Previously, `phabsend` uploads new diffs as long as the commit hash changes. That's suboptimal because sometimes the diff is exactly the same as before, the commit hash change is caused by a parent hash change, or commit message change which do not affect diff content. This patch adds a check examining actual diff contents to skip uploading new diffs in that case.

phabricator: add node and p1 to hg:meta property The "hg:meta" property is for extra metadata to reconstruct the patch. Previously it does not have node or parent information since I think by reading the patch again, the commit message will be mangled (like, added the "Differential Revision" line) and we cannot preserve the commit hash. However, the "parent" information could be useful. It could be helpful to locate the "base revision" so in case of a conflict applying the patch directly, we might be able to use 3-way merge to resolve it correctly. Note: "local:commits" is an existing "property" used by Phabricator that has the node and parent information. However, it lacks of timezone information and requires "author" and "authorEmail" to be separated. So we are using a different "property" - "hg:meta" to be distinguished from "local:commits".

phabricator: check associated Differential Revision from commit message Previously, only tags can "associate" a changeset to a Differential Revision. But the usual pattern (arc patch or hg phabread) is to put the Differential Revision URL in commit message. This patch makes the code read commit message to find associated Differential Revision if associated tags are not found. This makes some workflows possible. For example, if the author loses their repo, or switch to another computer, they can continue download their own patches from Phabricator and update them without needing to manually create tags.

tests: replace yet more calls to `python` with $PYTHON These are some simple cases. More to come in a future change. Reviewers: krbullock Reviewed By: krbullock Differential Revision: https://phab.mercurial-scm.org/D4

tests: capitalize Python when it's not used as a command name This avoids some false positives in an upcoming check-code rule. Reviewers: krbullock Reviewed By: krbullock Differential Revision: https://phab.mercurial-scm.org/D3

merge with stable

vfs: drop the 'mustaudit' API There are no remaining users of 'mustaudit' so we can safely drop the API. External user are unlikely from a quick research so no deprecation is added.

streamclone: stop using 'vfs.mustaudit = False' Now that each call disable the auditing on its own, we can safely drop this the mustaudit usage. No other code is modified.

vfs: simplify path audit disabling in stream clone The whole 'mustaudit' API is quite complex compared to its actual usage by its unique user in stream clone. Instead we add a "auditpath" parameter to 'vfs.__call_'. The stream clone code then explicitly open files with path auditing disabled. The 'mustaudit' API will be cleaned up in the next changeset.

auditor: add simple comment about repo.auditor and al Every once in a while, I get confused by what these are. Let us add a comment.

tag: make sure the repository is locked when tagging Otherwise, writing localtag can happen without the lock.

test: glob a line number in test-devel-warnings.t This make is simpler to edit the extensions file without side effect.