smartset: split generatorset classes to avoid cycle I uncovered a cycle manifesting in a memory leak by running `hgperfrevset '::tip'`. The cycle was due to generatorset.__init__ assigning a bound method to self.__contains__. Internet sleuthing revealed that assigning a bound method to an instance attribute always creates a cycle. This commit creates two new variants of generatorset for the special cases of ascending and descending generators. The special implementations of __contains__ have been extracted to these classes where they are defined as __contains__. generatorset now implements __new__ and changes the spawned type to one of the new classes if needed. Differential Revision: https://phab.mercurial-scm.org/D1780

merge: raise before running mergedriver if using IMM Merge driver scripts run in the working copy, so disable with IMM for now. Differential Revision: https://phab.mercurial-scm.org/D1781

scmutil: use a tuple of possible values instead of using startswith() This patch also adds a review comment which is helpful as inline comment. Differential Revision: https://phab.mercurial-scm.org/D1761

show: use revlog function to compute length of the longest shortest node As the core part of shortest() was extracted at 448725a2ef73, we no logner need a templater.

commands: use the new API to access hidden changesets in various commands In previous patches, we have added an internal API to unhide hidden changesets. This patch makes the following command use that api in nowarn mode i.e. there will be no warning while accessing hidden changesets. cat, diff, export, files, heads, identify, log, manifest, parents, status This patch also adds test demonstarting the behaviour. .. feature:: Accessing hidden changesets Set config option 'experimental.directaccess = True' to access hidden changesets from read only commands. Differential Revision: https://phab.mercurial-scm.org/D1735

scmutil: add utility fn to return repo object with user passed revs unhidden There has been a need for accessing hidden changesets by default without passing --hidden. This is currently done using the directaccess extension but is bit hacky. This patch adds a utility function to return a repo object having user passed revisions unhidden. This functionality will live behind a config option and won't be the default behaviour. There is also a config option added by this patch which tells whether we want to unhide only those revisions whose hashes are passed or should we consider revisions numbers also. Differential Revision: https://phab.mercurial-scm.org/D1733

repoview: add a new filtername for accessing hidden commits This patch adds a new filter 'visible-hidden' for repository and will be used to return a repo object with user passed revisions unhidden. Unlike the directaccess extension in fb-hgext and previous series adding the functionality, this time we introduce only one new filter as whether to warn user or not is handled by scmutil.unhidehashlikerevs(). Differential Revision: https://phab.mercurial-scm.org/D1734

revsetlang: add utility function to return hash like symbols from the tree Functionalities like unhiding changesets whose rev/hash is passed by the user required the knowledge of rev/hashes in the user provided specs. This patch adds functions which can parse tree object and return a list of such values. Differential Revision: https://phab.mercurial-scm.org/D1732

repoview: add visibilityexception argument to filterrevs() and related fns After this patch, filterrevs() can take an optional argument visibilityexceptions which is a set of revs which should be exception to being hidden. The visibilityexceptions will be passed to the function computing hidden revisions for that filtername and are considered there while calculating the set of hidden revs. Differential Revision: https://phab.mercurial-scm.org/D1747

repoview: add visibilityexceptions as an optional argument to repo.filtered() This will help us in having an API where we can pass the filtername and the visibilityexceptions to get a new repo object. Visibility exceptions are the revs which must be visible even they should in theory belong to the hidden set. They are required as there has been desire to have a functionality to access hidden changesets using certain commands without passing --hidden. After this patch we can make those changesets visibility exceptions so that we can access them without requiring a unfiltered repo. Differential Revision: https://phab.mercurial-scm.org/D1746

streamclone: move wire protocol status code from wireproto command This consolidates the code for the streaming clone wire protocol format into streamclone.py. It also eliminates a generator wrapper, which might make streaming clones slightly faster. Differential Revision: https://phab.mercurial-scm.org/D1754

histedit: add ui.log for action count Differential Revision: https://phab.mercurial-scm.org/D1751

run-tests: extract sorting of tests to own function TestRunner._run() is a large function and is difficult to follow. Let's extract the test sorting to its own function to make it shorter. When I refactored run-tests.py several years ago, I put a lot of functionality in methods. The prevailing Mercurial style is to use functions - not classes - where possible. While refactoring the code, I decided to undo this historical mistake of mine by moving the code to a standalone function. Differential Revision: https://phab.mercurial-scm.org/D1750

run-tests: remove dead code related to temp directory Differential Revision: https://phab.mercurial-scm.org/D1749

rebase: switch ui.log calls to common style The old style raised errors in some cases. Differential Revision: https://phab.mercurial-scm.org/D1748

hgweb: link to successors of obsoleted changesets _siblings() prepare various useful properties to use in templates. This function usually prepares parents and children of changesets for use in hgweb templates, but it can be used for successors too. It's needed because item['successors'] is a _hybrid object that works well when used in regular templates, but in hgweb templates work slightly differently and can't get hex nodes of the successors, which are required for these links to work.

hgweb: display fate of obsolete changesets Operations that obsolete changesets store enough metadata to explain what happened after the fact. One way to get that metadata is showsuccsandmarkers function, which returns a list of successors of a particular changeset and appropriate obsolescence markers. Templates have a set of experimental functions that have names starting with obsfate. This patch uses some of these functions to interpret output of succsandmarkers() and produce human-friendly messages that describe what happened to an obsolete changeset, e.g. "pruned" or "rewritten as 6:3de5eca88c00". In commonentry(), succsandmarkers property is made callable so it's only executed on demand; this saves time when changeset is not obsolete, and also in e.g. /shortlog view, where there are a lot of changesets, but we don't need to show each and every one in detail. In spartan theme, succsandmarkers is used instead of the simple "obsolete: yes", in other themes a new line is added to /rev page.

test-ssh: stabilize for Windows Previously, this complained: remote: '.' is not recognized as an internal or external command, remote: operable program or batch file. Making this a python script apparently revealed some races[1]. Thanks to Yuya for suggesting this. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-December/109094.html

templater: register keywords to defaults table Since the keywords are permanent, there should be no need to pass them by a temporary mapping.

templater: drop unneeded resources from conflict-marker data Follow-up for 32c278eb876f and f1c54d003327.

templater: rewrite docstring of templater.__init__() More importantly, this patch adds what the cache is.

rebase: don't take out a dirstate guard for in-memory rebase Since IMM doesn't affect the dirstate, it's not needed, and might be faster. Differential Revision: https://phab.mercurial-scm.org/D1745

test-split: stabilize for Windows - $PYTHON needs to be quoted when used as an executable in $HGEDITOR. This avoids the error "'c' is not recognized as an internal or external command". - seq.py is printing out CRLF, and then the subsequent `sed` script seems to convert to LF on MSYS. IDK if python print statements can be made to print LF on Windows, and I'm pretty sure CRLF is baked into some other tests. - A stray glob was causing the 'obsstore-off' case to report 'no result code from test'. - When I ran with --debug, the `hg diff` commands in the test both printed color sequences, and paused the output as it was run through the pager.

lfs: use ui.note() and ui.debug() instead of ui.write() and their flags Even though the upload/download message is still in a ui.verbose check, I switched that to ui.note() too so that the 'ui.note' label is applied. The debug message is no longer marked for translation because check-code complained.

lfs: only hardlink between the usercache and local store if the blob verifies This fixes the issue where verify (and other read commands) would propagate corrupt blobs. I originalled coded this to only hardlink if 'verify=True' for store.read(), but then good blobs weren't being linked, and this broke a bunch of tests. (The blob in repo5 that is being corrupted seems to be linked into repo5 in the loop running dumpflog.py prior to it being corrupted, but only if verify=False is handled too.) It's probably better to do a one time extra verification in order to create these files, so that the repo can be copied to a removable drive. Adding the same check to store.write() was only for completeness, but also needs to do a one time extra verification to avoid breaking tests.

lfs: verify lfs object content when transferring to and from the remote store This avoids inserting corrupt files into the usercache, and local and remote stores. One down side is that the bad file won't be available locally for forensic purposes after a remote download. I'm thinking about adding an 'incoming' directory to the local lfs store to handle the download, and then move it to the 'objects' directory after it passes verification. That would have the additional benefit of not concatenating each transfer chunk in memory until the full file is transferred. Verification isn't needed when the data is passed back through the revlog interface or when the oid was just calculated, but otherwise it is on by default. The additional overhead should be well worth avoiding problems with file based remote stores, or buggy lfs servers. Having two different verify functions is a little sad, but the full data of the blob is mostly passed around in memory, because that's what the revlog interface wants. The upload function, however, chunks up the data. It would be ideal if that was how the content is always handled, but that's probably a huge project. I don't really like printing the long hash, but `hg debugdata` isn't a public interface, and is the only way to get it. The filelog and revision info is nowhere near this area, so recommending `hg verify` is the easiest thing to do.

lfs: narrow the exceptions that trigger a transfer retry The retries were added to workaround TCP RESETs in fb-experimental fc8c131314a9. I have no idea if that's been debugged yet, but this wide net caught local I/O errors, bad hostnames and other things that shouldn't be retried. The next patch will validate objects as they are uploaded, and there's no need to retry those errors. The spec[1] does mention that certain http errors can be retried, including 500. But let's work through the corruption detection issues first. [1] https://github.com/git-lfs/git-lfs/blob/master/docs/api/batch.md

test-lfs: add tests around corrupted lfs objects These are mostly tests against file:// based remote stores, because that's what we have the most control over. The test uploading a corrupt blob to lfs-test-server demonstrates an overly broad exception handler in the retry loop. A corrupt blob is actually transferred in a download, but eventually caught when it is accessed (only after it leaves the corrupt file in a couple places locally). I don't think we want to trust random 3rd party implementations, and this would be a problem if there were a `debuglfsdownload` command that simply cached the files. And given the cryptic errors, we should probably validate the file hash locally before uploading, and also after downloading.

lfs: add note messages indicating what store holds the lfs blob The following corruption related patches were written prior to adding the user level cache, and it took awhile to track down why the tests changed. (It generally made things more resilient.) But I think this will be useful to the end user as well. I didn't make it --debug level, because there can be a ton of info coming out of clone/push/pull --debug. The pointers are sorted for test stability. I opted for ui.note() instead of checking ui.verbose and then using ui.write() for convenience, but I see most of this extension does the latter. I have no idea what the preferred form is.

tests: teach `f` to handle sha256 checksums