Tue, 03 Mar 2015 21:17:29 -0500 subrepo: explicitly request clean and unknown files in status for git's add
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.
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.
Fri, 06 Mar 2015 00:14:22 +0900 dirstate: make sure rootdir ends with directory separator (issue4557) stable
Yuya Nishihara <yuya@tcha.org> [Fri, 06 Mar 2015 00:14:22 +0900] rev 24198
dirstate: make sure rootdir ends with directory separator (issue4557) ntpath.join() of Python 2.7.9 does not work as expected if root is a UNC path to top of share. This patch doesn't take care of os.altsep, '/' on Windows, because root should be normalized by realpath().
Wed, 04 Mar 2015 17:24:12 +0100 i18n-de: fix a typo in the german translation stable
Alexander Becher <Alexander.Becher@RuD-Steuerungstechnik.De> [Wed, 04 Mar 2015 17:24:12 +0100] rev 24197
i18n-de: fix a typo in the german translation
Tue, 03 Mar 2015 17:28:05 -0600 histedit: fix style of new error message
Matt Mackall <mpm@selenic.com> [Tue, 03 Mar 2015 17:28:05 -0600] rev 24196
histedit: fix style of new error message - lowercase - no punctuation - brief - short node
Wed, 04 Feb 2015 15:17:13 -0500 Makefile: allow setting HGTESTFLAGS in shell environment for TESTFLAGS
Augie Fackler <augie@google.com> [Wed, 04 Feb 2015 15:17:13 -0500] rev 24195
Makefile: allow setting HGTESTFLAGS in shell environment for TESTFLAGS I keep wanting to run 'make tests', but I forget to set TESTFLAGS='-j 16' or whatever is reasonable for my machine. This lets me just set it once in my shell settings and forget it.
Wed, 04 Feb 2015 12:26:16 -0500 Makefile: introduce testpy-% target for testing with a specifc Python
Augie Fackler <augie@google.com> [Wed, 04 Feb 2015 12:26:16 -0500] rev 24194
Makefile: introduce testpy-% target for testing with a specifc Python This makes it easy to do 'make testpy-2.4.6 TESTFLAGS="-j 16"' and the Makefile will build Python if needed and then run tests (with -j 16) with the resulting Python. You can set the environment variable HGPYTHONS to a nice location on your machine to cache the Python builds globally. If that's not set, it builds them inside build/pythons.
Fri, 27 Feb 2015 17:35:07 -0500 extdiff: expand tildes and variables in paths to user-supplied diff programs
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Fri, 27 Feb 2015 17:35:07 -0500] rev 24193
extdiff: expand tildes and variables in paths to user-supplied diff programs
Sun, 22 Feb 2015 15:40:36 +0100 setup.py: do not install c extensions on pypy
Joan Massich <mailsik@gmail.com> [Sun, 22 Feb 2015 15:40:36 +0100] rev 24192
setup.py: do not install c extensions on pypy These extensions are slower on pypy because pypy has a JIT compiler. And also, they often do not compile (it depends on the pypy configuration).
Mon, 02 Mar 2015 14:52:04 +0100 copyright: update to 2015
Jesus Cea <jcea@jcea.es> [Mon, 02 Mar 2015 14:52:04 +0100] rev 24191
copyright: update to 2015 Many files and translations have an outdated copyright date. Change that to the correct "2005-2015" dates.
Wed, 21 Jan 2015 22:09:32 -0500 changegroup: emit full-replacement deltas if either revision is censored
Mike Edgar <adgar@google.com> [Wed, 21 Jan 2015 22:09:32 -0500] rev 24190
changegroup: emit full-replacement deltas if either revision is censored To ensure that exchanged deltas in the presence of censored revisions can always be applied to the recipient repository, the deltas must replace the entire base text. To make this restriction reasonably enforceable, the delta must do so with a single patch operation. For background and broader design of the censorship feature, see: http://mercurial.selenic.com/wiki/CensorPlan
Fri, 06 Feb 2015 11:04:55 -0800 log: make -fr show complete history from the given revs
Durham Goode <durham@fb.com> [Fri, 06 Feb 2015 11:04:55 -0800] rev 24189
log: make -fr show complete history from the given revs Right now it's very obtuse to show the history of a particular rev (hg log -r 'reverse(::foo)'). This changes the -f option to make it follow history for the revs specified by -r. The current -f -r behavior is to limit the result of -r to only the commits that are ancestors of the current working copy. Changing this is a bit of a BC break, but the old behavior is A) rare, B) easy to emulate (& ::.), and C) currently undefined. The new behavior is frequently requested enough that I think the change is worth it.
Tue, 24 Feb 2015 14:12:13 +0100 util: accept "now, today, yesterday" for dates even the locale is not english
André Klitzing <aklitzing@gmail.com> [Tue, 24 Feb 2015 14:12:13 +0100] rev 24188
util: accept "now, today, yesterday" for dates even the locale is not english Hi there! Fixed date names are helpful for automated systems. So it is possible to use english date parameter even if the underlying system uses another locale. We have here a jenkins with build jobs on different slaves that will do some operations with "dates" parameter. Some systems uses English locale and some systems uses German locale. So we needed to configure the job to uses other date names. As this is really annoying to keep the systems locale in mind for some operations I looked into util.py. It would be helpful for automated systems if the "default English" date names would even usable on other locales. I attached a simple patch for this. Best regards André Klitzing
Fri, 27 Feb 2015 14:26:22 -0800 copies: only calculate 'addedinm[12]' sets once
Martin von Zweigbergk <martinvonz@google.com> [Fri, 27 Feb 2015 14:26:22 -0800] rev 24187
copies: only calculate 'addedinm[12]' sets once Pass the addedinm1 and addedinm2 instead of m1, m2, ma into _computenonoverlap() instead of calculating the sets twice.
Fri, 27 Feb 2015 14:03:01 -0800 copies: calculate 'bothnew' from manifestdict.filesnotin()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 27 Feb 2015 14:03:01 -0800] rev 24186
copies: calculate 'bothnew' from manifestdict.filesnotin() In the same spirit as the previous change, let's now calculate the 'bothnew' variable using manifestdict.filesnotin().5D
Fri, 27 Feb 2015 14:02:30 -0800 copies: replace _nonoverlap() by calls to manifestdict.filesnotin()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 27 Feb 2015 14:02:30 -0800] rev 24185
copies: replace _nonoverlap() by calls to manifestdict.filesnotin() Now that we have manifestdict.filesnotin(), we can write _nonoverlap() in terms of that method instead, enabling future speedups when filesnotin() gets optimized, and perhaps making the code a little clearer at the same time.
Fri, 27 Feb 2015 13:57:37 -0800 copies: move code into new manifestdict.filesnotin() method
Martin von Zweigbergk <martinvonz@google.com> [Fri, 27 Feb 2015 13:57:37 -0800] rev 24184
copies: move code into new manifestdict.filesnotin() method copies._computeforwardmissing() finds files in one context that is not in the other. Let's move this code into a new method on manifestdict, so m1.filesnotin(m2) can be optimized for various types of manifests (we expect more types of manifests soon).
Fri, 27 Feb 2015 23:30:42 -0500 subrepo: warn when adding already tracked files in gitsubrepo
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Feb 2015 23:30:42 -0500] rev 24183
subrepo: warn when adding already tracked files in gitsubrepo This follows normal Mercurial rules, and the message is lifted from workingctx.add(). The file is printed with abs() to be consistent with how it is printed in workingctx, even though that is inconsistent with how added files are printed in verbose mode. Further, the 'already tracked' notifications come after all of the files that are added are printed, like in Mercurial. As a side effect, we now have the reject list to return to the caller, so that 'hg add' exits with the proper code. It looks like an abort occurs if git fails to add the file. Prior to touching 'snake.python' in the test, this was the result of attempting to add the file after a 'git rm': fatal: pathspec 'snake.python' did not match any files abort: git add error 128 in s (in subrepo s) I'm not sure what happens when git is a deep subrepo, but the 'in s' and 'in subrepo s' from @annotatesubrepoerror are redundant here. Maybe we should stat the files before invoking git to catch this case and print out the prettier hg message? The other thing missing from workingctx.add() is the call to scmutil.checkportable(), but that would need to borrow the parent's ui object.
Thu, 26 Feb 2015 15:53:54 -0500 subrepo: don't exclude files in .hgignore when adding to git
Matt Harbison <matt_harbison@yahoo.com> [Thu, 26 Feb 2015 15:53:54 -0500] rev 24182
subrepo: don't exclude files in .hgignore when adding to git The previous test gave a false success because only an hg-ignored pattern was specified. Therefore match.files() was empty, and it fell back to the files unknown to git. The simplest fix is to always consider what is unknown to git, as well as anything specified explicitly. Files that are ignored by git can only be introduced by an explicit mention in match.files().
Wed, 14 Jan 2015 01:15:26 +0100 dirstate: clarify comment about leaving normal files undef if changed 'now'
Mads Kiilerich <madski@unity3d.com> [Wed, 14 Jan 2015 01:15:26 +0100] rev 24181
dirstate: clarify comment about leaving normal files undef if changed 'now' Clarify that they only are saved as undef if they were marked as normal and changed in the same second.
Sun, 18 Jan 2015 02:38:57 +0100 spelling: fixes from proofreading of spell checker issues
Mads Kiilerich <madski@unity3d.com> [Sun, 18 Jan 2015 02:38:57 +0100] rev 24180
spelling: fixes from proofreading of spell checker issues
(0) -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip