manifest: move pure parsing code out of pure This lets us transition more smoothly.

manifest.c: new extension code to lazily parse manifests This lets us iterate manifests in order, but do a _lot_ less work in the common case when we only care about a few manifest entries. Many thanks to Mike Edgar for reviewing this in advance of it going out to the list, which caught many things I missed. This version of the patch includes C89 fixes from Sean Farley and many correctness/efficiency cleanups from Martin von Zweigbergk. Thanks to both!

workingctx: use normal dirs() instead of dirstate.dirs() The workingctx class was using dirstate.dirs() as it's implementation. The sparse extension maintains a pruned down version of the dirstate, so this resulted in the workingctx reporting an incorrect listing of directories during merge calculations (it was detecting directory renames when it shouldn't have). The fix is to use the default implementation, which uses workingctx._manifest, which unions the manifest with the dirstate to produce the correct overall picture. This also produces more accurate output since it will no longer return directories that have been entirely deleted in the dirstate. Tests will be added to the sparse extension to detect regressions for this.

merge with stable

subrepo: only fetch unknown files from git when explicitly requested

subrepo: always return scmutil.status() from gitsubrepo.status() This was accidentally left out of c95db3208a33.

subrepo: explicitly request clean and unknown files in status for git's add No behavior changes here since gitsubrepo.status() doesn't currently populate clean, and ignores whether unknown files were actually requested. But this is in line with other calls to status, and should avoid future surprises.

largefiles: handle logging from outside the repo It's probably possible to refactor so that the 'if m._cwd' check isn't necessary, but the False case is the typical case (i.e. run from the root of the repo), and simpler to read. An exact path to a largefile from outside the repo was previously ignored. match.rel('.hglf') will handle figuring out both the correct '../' length to the standin directory if inside the repo, or path/to/repo from outside, at the cost of a pconvert() to keep the patterns using '/' on Windows.

largefiles: don't prefix standin patterns with '.hglf' when logging When logging '.hglf/foo', the pattern list was being transformed from ['.hglf/foo'] into ['.hglf/foo', '.hglf/.hglf/foo']. Aside from the pathological case of somebody getting a directory named '.hglf' created inside the standing directory, the old code shouldn't have had any bad effects. (amended by mpm to sort patterns for test stability and not upset check-code)

largefiles: teach log to handle patterns Adding the standin to the patterns list was (possibly) harmless before, but was wrong, because the pattern list was already updated above that code. Now that patterns are handled, it was actually harmful. For example, in this test: $ hg log -G glob:**another* the adjusted pattern list would have been: ['glob:**another*', '.hglf/.', 'glob:.hglf/**another*'] which causes every largefile in the root to be matched. I'm not sure why 'glob:a*' picks up the rename of a -> b commit in test-log.t, but a simple 'a' doesn't. But it doesn't appear to be caused by the largefiles extension.