Wed, 12 Mar 2014 13:12:26 -0400 synthrepo: move from dict() construction to {} literals
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:12:26 -0400] rev 20672
synthrepo: move from dict() construction to {} literals The latter are both faster and more consistent across Python 2 and 3.
Wed, 12 Mar 2014 13:00:51 -0400 wireproto: remove todict() and use {} literals instead
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:00:51 -0400] rev 20671
wireproto: remove todict() and use {} literals instead
Tue, 11 Mar 2014 16:19:08 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Tue, 11 Mar 2014 16:19:08 -0500] rev 20670
merge with stable
Mon, 10 Mar 2014 15:00:41 -0500 templater: deprecate --style now that -T exists
Matt Mackall <mpm@selenic.com> [Mon, 10 Mar 2014 15:00:41 -0500] rev 20669
templater: deprecate --style now that -T exists
Sat, 08 Mar 2014 17:38:50 -0600 templating: make -T much more flexible
Matt Mackall <mpm@selenic.com> [Sat, 08 Mar 2014 17:38:50 -0600] rev 20668
templating: make -T much more flexible It can now accept styles and paths and references to settings in [templates].
Sat, 08 Mar 2014 16:14:08 -0600 changeset_templater: remove use_template method
Matt Mackall <mpm@selenic.com> [Sat, 08 Mar 2014 16:14:08 -0600] rev 20667
changeset_templater: remove use_template method
Sat, 08 Mar 2014 16:01:58 -0600 cmdutil: make helper function to process template args
Matt Mackall <mpm@selenic.com> [Sat, 08 Mar 2014 16:01:58 -0600] rev 20666
cmdutil: make helper function to process template args
Sat, 08 Mar 2014 15:27:25 -0600 commands: add -T alternative to --template
Matt Mackall <mpm@selenic.com> [Sat, 08 Mar 2014 15:27:25 -0600] rev 20665
commands: add -T alternative to --template
Fri, 07 Mar 2014 14:29:26 -0500 config: clarify and exemplify the user name in the sample config file
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Fri, 07 Mar 2014 14:29:26 -0500] rev 20664
config: clarify and exemplify the user name in the sample config file
Mon, 10 Mar 2014 01:01:43 +0900 templater: make strings in template expressions be "string-escape"-ed correctly stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 10 Mar 2014 01:01:43 +0900] rev 20663
templater: make strings in template expressions be "string-escape"-ed correctly Changeset 64b4f0cd7336 (released with 2.8.1) fixed "recursively evaluate string literals as templates" problem (issue4102) by moving the location of "string-escape"-ing from "tokenizer()" to "compiletemplate()". But some parts in template expressions below are not processed by "compiletemplate()", and it may cause unexpected result. - 'expr' of 'if(expr, then, else)' - 'expr's of 'ifeq(expr, expr, then, else)' - 'sep' of 'join(list, sep)' - 'text' and 'style' of 'rstdoc(text, style)' - 'text' and 'chars' of 'strip(text, chars)' - 'pat' and 'repl' of 'sub(pat, repl, expr)' For example, '\n' of "{join(extras, '\n')}" is not "string-escape"-ed and treated as a literal '\n'. This breaks "Display the contents of the 'extra' field, one per line" example in "hg help templates". Just "string-escape"-ing on each parts above may not work correctly, because inside expression of nested ones already applies "string-escape" on string literals. For example: - "{join(files, '\n')}" doesn't return "string-escape"-ed string, but - "{join(files, if(branch, '\n', '\n'))}" does To fix this problem, this patch does: - introduce "rawstring" token and "runrawstring" method to handle strings not to be "string-escape"-ed correctly, and - make "runstring" method return "string-escape"-ed string, and delay "string-escape"-ing until evaluation This patch invokes "compiletemplate()" with "strtoken=exp[0]" in "gettemplate()", because "exp[1]" is not yet evaluated. This code path is tested via mapping ("expr % '{template}'"). In the other hand, this patch invokes it with "strtoken='rawstring'" in "_evalifliteral()", because "t" is the result of "arg" evaluation and it should be "string-escape"-ed if "arg" is "string" expression. This patch doesn't test "string-escape"-ing on 'expr' of 'if(expr, then, else)', because it doesn't affect the result.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip