Mon, 26 Jan 2015 15:52:46 -0500 test-revset: add tests for missing function output
Augie Fackler <augie@google.com> [Mon, 26 Jan 2015 15:52:46 -0500] rev 24220
test-revset: add tests for missing function output An upcoming change will slightly alter behavior here. Adding the test now so the output change stands out in the later changeset.
Mon, 26 Jan 2015 14:32:30 -0500 revset: use UnknownIdentifier where appropriate
Augie Fackler <augie@google.com> [Mon, 26 Jan 2015 14:32:30 -0500] rev 24219
revset: use UnknownIdentifier where appropriate
Mon, 26 Jan 2015 14:31:48 -0500 fileset: use UnknownIdentifier where appropriate
Augie Fackler <augie@google.com> [Mon, 26 Jan 2015 14:31:48 -0500] rev 24218
fileset: use UnknownIdentifier where appropriate
Mon, 26 Jan 2015 14:31:01 -0500 error: add a new UnknownIdentifier error type
Augie Fackler <augie@google.com> [Mon, 26 Jan 2015 14:31:01 -0500] rev 24217
error: add a new UnknownIdentifier error type This will be used by the revset and fileset code to communicate more specific errors to higher levels so that we might be able to offer suggestions about what function might have been similar.
Mon, 24 Nov 2014 16:42:49 -0500 log: display closing-branch nodes as "_" (BC)
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Mon, 24 Nov 2014 16:42:49 -0500] rev 24216
log: display closing-branch nodes as "_" (BC) In plain `hg log` there is no indication that a commit closes a branch. You can use hg log --debug, but this is too verbose. A simple idea copied from thg and other graphical viewers is to display the node for a closing-branch commit as a horizontal line. I think this technically is a BC if we consider the graphlog to be part of the stdout API, but I really can't imagine who the hell is parsing the graphlog to determine information about commits.
Fri, 06 Mar 2015 17:00:42 -0600 manifest: move pure parsing code out of pure
Matt Mackall <mpm@selenic.com> [Fri, 06 Mar 2015 17:00:42 -0600] rev 24215
manifest: move pure parsing code out of pure This lets us transition more smoothly.
Tue, 13 Jan 2015 14:31:38 -0800 manifest.c: new extension code to lazily parse manifests
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!
Thu, 05 Mar 2015 22:16:28 -0800 workingctx: use normal dirs() instead of dirstate.dirs()
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.
Thu, 05 Mar 2015 15:52:07 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Thu, 05 Mar 2015 15:52:07 -0600] rev 24212
merge with stable
Tue, 03 Mar 2015 21:31:16 -0500 subrepo: only fetch unknown files from git when explicitly requested
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
Tue, 03 Mar 2015 21:24:16 -0500 subrepo: always return scmutil.status() from gitsubrepo.status()
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.
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
Fri, 27 Feb 2015 21:42:58 +0100 merge-tools: configuration for Beyond Compare on OS X
Mads Kiilerich <madski@unity3d.com> [Fri, 27 Feb 2015 21:42:58 +0100] rev 24179
merge-tools: configuration for Beyond Compare on OS X Based on the Linux configuration entry.
Wed, 21 Jan 2015 00:02:17 +0100 convert: when converting from monotone, use the number 1 for close in extras
Mads Kiilerich <madski@unity3d.com> [Wed, 21 Jan 2015 00:02:17 +0100] rev 24178
convert: when converting from monotone, use the number 1 for close in extras Monotone used '1' for close while core Mercurial use 1. Now, for consistency, use the same value everywhere. It will be stored as a string anyway and the change will not make any real difference. (The actual value of 'close' doesn't matter as long as extras has such a key.)
Mon, 02 Mar 2015 15:07:18 -0800 hgweb: extract changeset template mapping generation to own function
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 02 Mar 2015 15:07:18 -0800] rev 24177
hgweb: extract changeset template mapping generation to own function Similar in spirit to 513d47905114, I want to write an extension to make available extra template keywords so hgweb templates can include extra data. To do this today requires monkeypatching the templater, which I think is the wrong place to perform this modification. This patch extracts the creation of the templater arguments to a standalone function - one that can be monkeypatched by extensions. I would very much like for extensions to be able to inject extra templater parameters into *any* template. However, I'm not sure the best way to facilitate this, as hgweb commands invoke the templater before returning and we want the extensions to have access to rich data structures like the context instances. We need cooperation inside hgweb command functions. The use case screams for something like internal-only "hooks." This is exactly what my (rejected) "events" patch series provided. Perhaps that feature should be reconsidered...
Mon, 02 Mar 2015 17:32:37 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Mon, 02 Mar 2015 17:32:37 -0600] rev 24176
merge with stable
Wed, 25 Feb 2015 18:12:01 -0500 revrange: don't parse revset aliases as hash prefixes (issue4553)
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 25 Feb 2015 18:12:01 -0500] rev 24175
revrange: don't parse revset aliases as hash prefixes (issue4553) If a user has a revsetalias defined, it is their explicit wish for this alias to be parsed as a revset and nothing else. Although the case of the alias being short enough and only contain the letters a-f is probably kind of rare, it may still happen.
Tue, 24 Feb 2015 08:49:22 +0100 subrepos: support adding files in git subrepos
Mathias De Maré <mathias.demare@gmail.com> [Tue, 24 Feb 2015 08:49:22 +0100] rev 24174
subrepos: support adding files in git subrepos This support includes correct matching, so includes, excludes and patterns are all supported.
Sun, 15 Feb 2015 17:29:10 -0500 subrepo: return only the manifest keys from hgsubrepo.files()
Matt Harbison <matt_harbison@yahoo.com> [Sun, 15 Feb 2015 17:29:10 -0500] rev 24173
subrepo: return only the manifest keys from hgsubrepo.files() This is in line with the other subrepo classes (i.e. only the filenames are returned). Archive iterates over the manifest keys, and since subrepo archive() uses this method, it does too now. This will allow largefiles to override its manifest keys to present the largefiles instead of the standins. Once in place, we shouldn't need the copy/paste overrides of archive and subrepo archive in largefiles, that don't quite behave like the core methods they are overriding.
(0) -10000 -3000 -1000 -300 -100 -48 +48 +100 +300 +1000 +3000 +10000 tip