Sun, 01 Mar 2015 18:35:29 -0500 largefiles: handle logging from outside the repo
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.
Sun, 01 Mar 2015 14:21:54 -0500 largefiles: don't prefix standin patterns with '.hglf' when logging
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)
Sat, 28 Feb 2015 23:42:38 -0500 largefiles: teach log to handle patterns
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.
Thu, 05 Mar 2015 13:21:57 -0600 check-code: allow disabling msys path check
Matt Mackall <mpm@selenic.com> [Thu, 05 Mar 2015 13:21:57 -0600] rev 24205
check-code: allow disabling msys path check
Thu, 08 Jan 2015 23:05:45 +0900 revset: extend fullreposet to make "null" revision magically appears in set
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.
Sat, 10 Jan 2015 18:09:25 +0900 revset: duplicate spanset.__contains__ to fullreposet for modification
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)
Sat, 10 Jan 2015 14:49:50 +0900 revset: have all() filter out null revision
Yuya Nishihara <yuya@tcha.org> [Sat, 10 Jan 2015 14:49:50 +0900] rev 24202
revset: have all() filter out null revision I'm not sure if "all()" should filter out "null", but "all()" is stated as 'the same as "0:tip"' (except that it doesn't reorder the subset, I think.) This patch is intended to avoid exposing a fullreposet to graphmod.dagwalker(), which would result in strange drawing in future version: | o changeset: 0:f8035bb17114 | user: test | date: Thu Jan 01 00:00:00 1970 +0000 | summary: add a caused by: parents = sorted(set([p.rev() for p in ctx.parents() if p.rev() in revs])) We cannot add "and p.rev() != nullrev" here because revs may actually include "null" revision.
Sat, 10 Jan 2015 16:41:36 +0900 revset: drop unnecessary calls of getall() with empty argument
Yuya Nishihara <yuya@tcha.org> [Sat, 10 Jan 2015 16:41:36 +0900] rev 24201
revset: drop unnecessary calls of getall() with empty argument If x is None, getall(repo, subset, x) == subset.
Wed, 04 Mar 2015 21:47:07 +0900 graphlog: do not bypass commands.log so that -fr works
Yuya Nishihara <yuya@tcha.org> [Wed, 04 Mar 2015 21:47:07 +0900] rev 24200
graphlog: do not bypass commands.log so that -fr works Since 8b4b9ee6001a, opts dict can be modified in commands.log() before calling cmdutil.graphlog().
Wed, 21 Jan 2015 14:45:24 -0800 histedit: add a config allowing changing histedit rule line length limit
Mateusz Kwapich <mitrandir@fb.com> [Wed, 21 Jan 2015 14:45:24 -0800] rev 24199
histedit: add a config allowing changing histedit rule line length limit Since many users are using terminals wider than 80 chars there should be an option to have longer lines in histedit editor. Even if the summary line is shorter than 80 chars after adding action line prefixes (like "pick 7c2fd3b9020c") it doesn't fit there anymore. Setting it to for example 110 would be a nice option to have.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip