Augie Fackler <augie@google.com> [Tue, 13 Jan 2015 14:31:38 -0800] rev 24214
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!
Durham Goode <durham@fb.com> [Thu, 05 Mar 2015 22:16:28 -0800] rev 24213
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.
Matt Mackall <mpm@selenic.com> [Thu, 05 Mar 2015 15:52:07 -0600] rev 24212
merge with stable
Matt Harbison <matt_harbison@yahoo.com> [Tue, 03 Mar 2015 21:31:16 -0500] rev 24211
subrepo: only fetch unknown files from git when explicitly requested
Matt Harbison <matt_harbison@yahoo.com> [Tue, 03 Mar 2015 21:24:16 -0500] rev 24210
subrepo: always return scmutil.status() from gitsubrepo.status()
This was accidentally left out of
c95db3208a33.
Matt Harbison <matt_harbison@yahoo.com> [Tue, 03 Mar 2015 21:17:29 -0500] rev 24209
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.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 01 Mar 2015 18:35:29 -0500] rev 24208
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.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 01 Mar 2015 14:21:54 -0500] rev 24207
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)
Matt Harbison <matt_harbison@yahoo.com> [Sat, 28 Feb 2015 23:42:38 -0500] rev 24206
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.
Matt Mackall <mpm@selenic.com> [Thu, 05 Mar 2015 13:21:57 -0600] rev 24205
check-code: allow disabling msys path check
Yuya Nishihara <yuya@tcha.org> [Thu, 08 Jan 2015 23:05:45 +0900] rev 24204
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.
Yuya Nishihara <yuya@tcha.org> [Sat, 10 Jan 2015 18:09:25 +0900] rev 24203
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)