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.

check-code: allow disabling msys path check

revset: extend fullreposet to make "null" revision magically appears in set As per fullreposet.__and__, it can omit the range check of rev. Therefore, "null" revision is accepted automagically. It seems this can fix many query results involving null symbol. Originally, the simplest "(null)" query did fail if there were hidden revisions. Tests are randomly chosen. fullreposet mimics the behavior of localrepo, where "null" revision is not listed but contained.

revset: duplicate spanset.__contains__ to fullreposet for modification 1d7a2771aa36 says we should avoid function calls in __contains__, so super(fullreposet, self).__contains__(rev) is not an option. Actually the super call doubled the benchmark result of trivial query: revisions: 0) 678f53865c68 (tip when I wrote this patch) 1) rev == node.nullrev or super(fullreposet, self).__contains__(rev) revset #0: tip:0 0) wall 0.008441 comb 0.010000 user 0.010000 sys 0.000000 (best of 282) 1) wall 0.016152 comb 0.010000 user 0.010000 sys 0.000000 (best of 146)