facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-10 00:45:18 +03:00
Code Issues Projects Releases Wiki Activity
419a5a94fb
sapling/tests/test-command-template.t

3841 lines
99 KiB
Perl
Raw Normal View History

tests: unify test-command-template
2010-09-14 21:31:00 +04:00
$ hg init a
$ cd a
$ echo a > a
$ hg add a
$ echo line 1 > b
$ echo line 2 >> b
$ hg commit -l b -d '1000000 0' -u 'User Name <user@hostname>'
$ hg add b
$ echo other 1 > c
$ echo other 2 >> c
$ echo >> c
$ echo other 3 >> c
$ hg commit -l c -d '1100000 0' -u 'A. N. Other <other@place>'
$ hg add c
$ hg commit -m 'no person' -d '1200000 0' -u 'other@place'
$ echo c >> c
$ hg commit -m 'no user, no domain' -d '1300000 0' -u 'person'
$ echo foo > .hg/branch
$ hg commit -m 'new branch' -d '1400000 0' -u 'person'
$ hg co -q 3
$ echo other 4 >> d
$ hg add d
$ hg commit -m 'new head' -d '1500000 0' -u 'person'
$ hg merge -q foo
$ hg commit -m 'merge' -d '1500001 0' -u 'person'
Second branch starting at nullrev:
$ hg update null
0 files updated, 0 files merged, 4 files removed, 0 files unresolved
$ echo second > second
$ hg add second
$ hg commit -m second -d '1000000 0' -u 'User Name <user@hostname>'
created new head
$ echo third > third
$ hg add third
$ hg mv second fourth
$ hg commit -m third -d "2020-01-01 10:01"
templatekw: add default styles for hybrid types (issue3887) This allows elements like file_copies to be printed as 'name (source)' when used with join.
2013-04-16 18:44:29 +04:00
$ hg log --template '{join(file_copies, ",\n")}\n' -r .
fourth (second)
commands: add -T alternative to --template
2014-03-09 01:27:25 +04:00
$ hg log -T '{file_copies % "{source} -> {name}\n"}' -r .
templater: properly handle file_copies with %
2013-02-22 23:45:46 +04:00
second -> fourth
templater: implement _hybrid.__contains__ so that ifcontains can accept dict 7678263f920c is fine for "{revset()}", but "i.values()[0]" does not work if each item has more than one values such as "{bookmarks}". This fixes the problem by using list.__contains__ or dict.__contains__ appropriately.
2015-02-18 17:01:33 +03:00
$ hg log -T '{rev} {ifcontains("fourth", file_copies, "t", "f")}\n' -r .:7
8 t
7 f
templater: properly handle file_copies with %
2013-02-22 23:45:46 +04:00
templatekw: make {rev} return wdirrev instead of None wdirrev/wdirnode identifiers are still experimental, but {node} is mapped to wdirnode. So {rev} should do the same for consistency. I'm not sure if templatekw can import scmutil. If not, we should move intrev() to node module.
2015-07-02 16:18:21 +03:00
Working-directory revision has special identifiers, though they are still
experimental:
$ hg log -r 'wdir()' -T '{rev}:{node}\n'
2147483647:ffffffffffffffffffffffffffffffffffffffff
templatekw: apply manifest template only if ctx.manifestnode() exists This will prevent crash by "hg log -r 'wdir()' -Tdefault". We could use the pseudo ff... hash introduced by 187c3ec3d83f, but it isn't proven idea yet. For now, I want to make "hg log" just works in order to test 'wdir()' revset. Note that unlike its name, "{manifest}" is not a list of files in that revision, but a pair of (manifestrev, manifestnode).
2015-03-14 11:58:18 +03:00
Some keywords are invalid for working-directory revision, but they should
never cause crash:
$ hg log -r 'wdir()' -T '{manifest}\n'
templater: handle SyntaxError when parsing ui.logtemplate Before, Mercurial would crash with a traceback ending with SyntaxError: unmatched quotes if you configured [ui] logtemplate = {rev}\n The SyntaxError is now catched and the string is re-parsed without requiring quotes.
2012-05-13 00:12:54 +04:00
Quoting for ui.logtemplate
$ hg tip --config "ui.logtemplate={rev}\n"
8
$ hg tip --config "ui.logtemplate='{rev}\n'"
8
$ hg tip --config 'ui.logtemplate="{rev}\n"'
8
templater: do not strip non-quote characters from template config Before this patch, the first and last characters were stripped from ui.logtemplate and template.* if they were the same. It could lead to a strange result as quotes are optional. See the test for example.
2016-03-27 11:42:19 +03:00
$ hg tip --config 'ui.logtemplate=n{rev}\n'
n8
templater: handle SyntaxError when parsing ui.logtemplate Before, Mercurial would crash with a traceback ending with SyntaxError: unmatched quotes if you configured [ui] logtemplate = {rev}\n The SyntaxError is now catched and the string is re-parsed without requiring quotes.
2012-05-13 00:12:54 +04:00
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
Make sure user/global hgrc does not affect tests
$ echo '[ui]' > .hg/hgrc
$ echo 'logtemplate =' >> .hg/hgrc
$ echo 'style =' >> .hg/hgrc
templating: make -T much more flexible It can now accept styles and paths and references to settings in [templates].
2014-03-09 03:38:50 +04:00
Add some simple styles to settings
$ echo '[templates]' >> .hg/hgrc
$ printf 'simple = "{rev}\\n"\n' >> .hg/hgrc
$ printf 'simple2 = {rev}\\n\n' >> .hg/hgrc
$ hg log -l1 -Tsimple
8
$ hg log -l1 -Tsimple2
8
Test templates and style maps in files:
$ echo "{rev}" > tmpl
$ hg log -l1 -T./tmpl
8
$ hg log -l1 -Tblah/blah
blah/blah (no-eol)
$ printf 'changeset = "{rev}\\n"\n' > map-simple
$ hg log -l1 -T./map-simple
8
templater: fix precedence of --style and --template options Since 266cfa7de44d, --template option is ignored if --style is specified, which is wrong according to the doc of show_changeset(): Display format will be the first non-empty hit of: 1. option 'template' 2. option 'style' ...
2014-09-30 18:15:56 +04:00
Template should precede style option
$ hg log -l1 --style default -T '{rev}\n'
8
test-command-template: add a short description of a temporary snippet This snippet was introduced by 942d64e0a1ee. Its purpose seems a bit obscure without historical context.
2015-04-24 21:17:14 +03:00
Add a commit with empty description, to ensure that the templates
test-command-template: minor clarification in comment
2015-04-26 20:43:01 +03:00
below will omit the description line.
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
templates-default: do not show description or summary if empty changeset_printer shows description only if ctx.description().strip() is not empty. The default template should do the same way.
2015-03-27 16:12:53 +03:00
$ echo c >> c
$ hg add c
$ hg commit -qm ' '
template-phases: do not show description or summary if empty This is a copy of 942d64e0a1ee, but applied to the phases template, which is itself almost a copy of the default template. Perhaps we should rewrite these templates to use the %include syntax afforded by config files. This change seems a bit too big for stable, though.
2015-04-24 21:52:12 +03:00
Default style is like normal output. Phases style should be the same
as default style, except for extra phase lines.
test-command-template: add a short description of a temporary snippet This snippet was introduced by 942d64e0a1ee. Its purpose seems a bit obscure without historical context.
2015-04-24 21:17:14 +03:00
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
$ hg log > log.out
$ hg log --style default > style.out
$ cmp log.out style.out || diff -u log.out style.out
template-phases: do not show description or summary if empty This is a copy of 942d64e0a1ee, but applied to the phases template, which is itself almost a copy of the default template. Perhaps we should rewrite these templates to use the %include syntax afforded by config files. This change seems a bit too big for stable, though.
2015-04-24 21:52:12 +03:00
$ hg log -T phases > phases.out
tests: work around differing hunk headers between GNU and Solaris diff The hunk headers specifying what lines the hunk apply to differ. They're irrelevant to the test, so just eliminate them from the output.
2015-07-21 01:39:15 +03:00
$ diff -U 0 log.out phases.out | egrep -v '^---|^\+\+\+|^@@'
template-phases: do not show description or summary if empty This is a copy of 942d64e0a1ee, but applied to the phases template, which is itself almost a copy of the default template. Perhaps we should rewrite these templates to use the %include syntax afforded by config files. This change seems a bit too big for stable, though.
2015-04-24 21:52:12 +03:00
+phase: draft
+phase: draft
+phase: draft
+phase: draft
+phase: draft
+phase: draft
+phase: draft
+phase: draft
+phase: draft
+phase: draft
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
$ hg log -v > log.out
$ hg log -v --style default > style.out
$ cmp log.out style.out || diff -u log.out style.out
template-phases: do not show description or summary if empty This is a copy of 942d64e0a1ee, but applied to the phases template, which is itself almost a copy of the default template. Perhaps we should rewrite these templates to use the %include syntax afforded by config files. This change seems a bit too big for stable, though.
2015-04-24 21:52:12 +03:00
$ hg log -v -T phases > phases.out
tests: work around differing hunk headers between GNU and Solaris diff The hunk headers specifying what lines the hunk apply to differ. They're irrelevant to the test, so just eliminate them from the output.
2015-07-21 01:39:15 +03:00
$ diff -U 0 log.out phases.out | egrep -v '^---|^\+\+\+|^@@'
template-phases: do not show description or summary if empty This is a copy of 942d64e0a1ee, but applied to the phases template, which is itself almost a copy of the default template. Perhaps we should rewrite these templates to use the %include syntax afforded by config files. This change seems a bit too big for stable, though.
2015-04-24 21:52:12 +03:00
+phase: draft
+phase: draft
+phase: draft
+phase: draft
+phase: draft
+phase: draft
+phase: draft
+phase: draft
+phase: draft
+phase: draft
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
templates: fix "log -q" output of default style It was changed at ad92c202bbcd unintentionally due to name conflicts.
2015-03-14 16:34:27 +03:00
$ hg log -q > log.out
$ hg log -q --style default > style.out
$ cmp log.out style.out || diff -u log.out style.out
template-phases: do not show description or summary if empty This is a copy of 942d64e0a1ee, but applied to the phases template, which is itself almost a copy of the default template. Perhaps we should rewrite these templates to use the %include syntax afforded by config files. This change seems a bit too big for stable, though.
2015-04-24 21:52:12 +03:00
$ hg log -q -T phases > phases.out
$ cmp log.out phases.out || diff -u log.out phases.out
templates: fix "log -q" output of default style It was changed at ad92c202bbcd unintentionally due to name conflicts.
2015-03-14 16:34:27 +03:00
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
$ hg log --debug > log.out
$ hg log --debug --style default > style.out
$ cmp log.out style.out || diff -u log.out style.out
template-phases: do not show description or summary if empty This is a copy of 942d64e0a1ee, but applied to the phases template, which is itself almost a copy of the default template. Perhaps we should rewrite these templates to use the %include syntax afforded by config files. This change seems a bit too big for stable, though.
2015-04-24 21:52:12 +03:00
$ hg log --debug -T phases > phases.out
$ cmp log.out phases.out || diff -u log.out phases.out
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
changeset_printer: display wdirrev/wdirnode values for workingctx Because we want to eliminate "if"s in the default template, it makes sense to display wdirrev/wdirnode values for now. wdir() is still experimental, so the output of "log -r'wdir()'" may change in future.
2015-07-04 11:19:49 +03:00
Default style of working-directory revision should also be the same (but
date may change while running tests):
$ hg log -r 'wdir()' | sed 's|^date:.*|date:|' > log.out
$ hg log -r 'wdir()' --style default | sed 's|^date:.*|date:|' > style.out
$ cmp log.out style.out || diff -u log.out style.out
$ hg log -r 'wdir()' -v | sed 's|^date:.*|date:|' > log.out
$ hg log -r 'wdir()' -v --style default | sed 's|^date:.*|date:|' > style.out
$ cmp log.out style.out || diff -u log.out style.out
$ hg log -r 'wdir()' -q > log.out
$ hg log -r 'wdir()' -q --style default > style.out
$ cmp log.out style.out || diff -u log.out style.out
$ hg log -r 'wdir()' --debug | sed 's|^date:.*|date:|' > log.out
$ hg log -r 'wdir()' --debug --style default \
> | sed 's|^date:.*|date:|' > style.out
$ cmp log.out style.out || diff -u log.out style.out
log: rewrite default template to use labels (issue2866) This is a complete rewrite of the default template to use labels. This seems ultimately useless to me in most cases. The biggest benefit of this patch to me seems to be a fairly complicated example of the templating engine. It was a lot of hard work to figure out the precise acceptable syntax, since it's almost undocumented. Hat tip to Steve Losh's smartlog template, which helped me figure out a lot of the syntax. Hopefully later I can use the present default log template as an example for documenting the templating engine. A test is attached. My goal was to match the --color=debug output, which may differ slightly in newlines from the actual ANSI escape codes output. I consider this an acceptable invisible deviation. There seems to be a considerable slowdown with this rewrite. Before: $ time hg log -T default -r .~100::. > /dev/null real 0m0.882s user 0m0.812s sys 0m0.064s $ time hg log -T default -r .~100::. > /dev/null real 0m0.872s user 0m0.796s sys 0m0.068s $ time hg log -T default -r .~100::. > /dev/null real 0m0.917s user 0m0.836s sys 0m0.076s After: $ time hg log -T default -r .~100::. > /dev/null real 0m1.480s user 0m1.392s sys 0m0.072s $ time hg log -T default -r .~100::. > /dev/null real 0m1.500s user 0m1.400s sys 0m0.088s $ time hg log -T default -r .~100::. > /dev/null real 0m1.462s user 0m1.364s sys 0m0.092s Following the maxim, "make it work, profile, make it faster, in that order", I deem this slowdown acceptable for now. I suspect but have not confirmed that a big slowdown comes from calling keywords twice in the file templates, once to test the existence of output and again to actually list the output. If so, a simple speedup might be to improve the templating engine to cache keywords when called more than once on the same revision. TODO: I found a bug while working on this. The following stack traces: hg log -r . -T '{ifcontains(phase, "secret public", "lol", "omg")}\n'
2014-10-04 03:48:56 +04:00
Default style should also preserve color information (issue2866):
$ cp $HGRCPATH $HGRCPATH-bak
$ cat <<EOF >> $HGRCPATH
> [extensions]
> color=
> EOF
$ hg --color=debug log > log.out
$ hg --color=debug log --style default > style.out
$ cmp log.out style.out || diff -u log.out style.out
template-phases: do not show description or summary if empty This is a copy of 942d64e0a1ee, but applied to the phases template, which is itself almost a copy of the default template. Perhaps we should rewrite these templates to use the %include syntax afforded by config files. This change seems a bit too big for stable, though.
2015-04-24 21:52:12 +03:00
$ hg --color=debug log -T phases > phases.out
tests: work around differing hunk headers between GNU and Solaris diff The hunk headers specifying what lines the hunk apply to differ. They're irrelevant to the test, so just eliminate them from the output.
2015-07-21 01:39:15 +03:00
$ diff -U 0 log.out phases.out | egrep -v '^---|^\+\+\+|^@@'
template-phases: do not show description or summary if empty This is a copy of 942d64e0a1ee, but applied to the phases template, which is itself almost a copy of the default template. Perhaps we should rewrite these templates to use the %include syntax afforded by config files. This change seems a bit too big for stable, though.
2015-04-24 21:52:12 +03:00
+[log.phase|phase: draft]
+[log.phase|phase: draft]
+[log.phase|phase: draft]
+[log.phase|phase: draft]
+[log.phase|phase: draft]
+[log.phase|phase: draft]
+[log.phase|phase: draft]
+[log.phase|phase: draft]
+[log.phase|phase: draft]
+[log.phase|phase: draft]
log: rewrite default template to use labels (issue2866) This is a complete rewrite of the default template to use labels. This seems ultimately useless to me in most cases. The biggest benefit of this patch to me seems to be a fairly complicated example of the templating engine. It was a lot of hard work to figure out the precise acceptable syntax, since it's almost undocumented. Hat tip to Steve Losh's smartlog template, which helped me figure out a lot of the syntax. Hopefully later I can use the present default log template as an example for documenting the templating engine. A test is attached. My goal was to match the --color=debug output, which may differ slightly in newlines from the actual ANSI escape codes output. I consider this an acceptable invisible deviation. There seems to be a considerable slowdown with this rewrite. Before: $ time hg log -T default -r .~100::. > /dev/null real 0m0.882s user 0m0.812s sys 0m0.064s $ time hg log -T default -r .~100::. > /dev/null real 0m0.872s user 0m0.796s sys 0m0.068s $ time hg log -T default -r .~100::. > /dev/null real 0m0.917s user 0m0.836s sys 0m0.076s After: $ time hg log -T default -r .~100::. > /dev/null real 0m1.480s user 0m1.392s sys 0m0.072s $ time hg log -T default -r .~100::. > /dev/null real 0m1.500s user 0m1.400s sys 0m0.088s $ time hg log -T default -r .~100::. > /dev/null real 0m1.462s user 0m1.364s sys 0m0.092s Following the maxim, "make it work, profile, make it faster, in that order", I deem this slowdown acceptable for now. I suspect but have not confirmed that a big slowdown comes from calling keywords twice in the file templates, once to test the existence of output and again to actually list the output. If so, a simple speedup might be to improve the templating engine to cache keywords when called more than once on the same revision. TODO: I found a bug while working on this. The following stack traces: hg log -r . -T '{ifcontains(phase, "secret public", "lol", "omg")}\n'
2014-10-04 03:48:56 +04:00
$ hg --color=debug -v log > log.out
$ hg --color=debug -v log --style default > style.out
$ cmp log.out style.out || diff -u log.out style.out
template-phases: do not show description or summary if empty This is a copy of 942d64e0a1ee, but applied to the phases template, which is itself almost a copy of the default template. Perhaps we should rewrite these templates to use the %include syntax afforded by config files. This change seems a bit too big for stable, though.
2015-04-24 21:52:12 +03:00
$ hg --color=debug -v log -T phases > phases.out
tests: work around differing hunk headers between GNU and Solaris diff The hunk headers specifying what lines the hunk apply to differ. They're irrelevant to the test, so just eliminate them from the output.
2015-07-21 01:39:15 +03:00
$ diff -U 0 log.out phases.out | egrep -v '^---|^\+\+\+|^@@'
template-phases: do not show description or summary if empty This is a copy of 942d64e0a1ee, but applied to the phases template, which is itself almost a copy of the default template. Perhaps we should rewrite these templates to use the %include syntax afforded by config files. This change seems a bit too big for stable, though.
2015-04-24 21:52:12 +03:00
+[log.phase|phase: draft]
+[log.phase|phase: draft]
+[log.phase|phase: draft]
+[log.phase|phase: draft]
+[log.phase|phase: draft]
+[log.phase|phase: draft]
+[log.phase|phase: draft]
+[log.phase|phase: draft]
+[log.phase|phase: draft]
+[log.phase|phase: draft]
templates: fix "log -q" output of default style It was changed at ad92c202bbcd unintentionally due to name conflicts.
2015-03-14 16:34:27 +03:00
$ hg --color=debug -q log > log.out
$ hg --color=debug -q log --style default > style.out
$ cmp log.out style.out || diff -u log.out style.out
template-phases: do not show description or summary if empty This is a copy of 942d64e0a1ee, but applied to the phases template, which is itself almost a copy of the default template. Perhaps we should rewrite these templates to use the %include syntax afforded by config files. This change seems a bit too big for stable, though.
2015-04-24 21:52:12 +03:00
$ hg --color=debug -q log -T phases > phases.out
$ cmp log.out phases.out || diff -u log.out phases.out
log: rewrite default template to use labels (issue2866) This is a complete rewrite of the default template to use labels. This seems ultimately useless to me in most cases. The biggest benefit of this patch to me seems to be a fairly complicated example of the templating engine. It was a lot of hard work to figure out the precise acceptable syntax, since it's almost undocumented. Hat tip to Steve Losh's smartlog template, which helped me figure out a lot of the syntax. Hopefully later I can use the present default log template as an example for documenting the templating engine. A test is attached. My goal was to match the --color=debug output, which may differ slightly in newlines from the actual ANSI escape codes output. I consider this an acceptable invisible deviation. There seems to be a considerable slowdown with this rewrite. Before: $ time hg log -T default -r .~100::. > /dev/null real 0m0.882s user 0m0.812s sys 0m0.064s $ time hg log -T default -r .~100::. > /dev/null real 0m0.872s user 0m0.796s sys 0m0.068s $ time hg log -T default -r .~100::. > /dev/null real 0m0.917s user 0m0.836s sys 0m0.076s After: $ time hg log -T default -r .~100::. > /dev/null real 0m1.480s user 0m1.392s sys 0m0.072s $ time hg log -T default -r .~100::. > /dev/null real 0m1.500s user 0m1.400s sys 0m0.088s $ time hg log -T default -r .~100::. > /dev/null real 0m1.462s user 0m1.364s sys 0m0.092s Following the maxim, "make it work, profile, make it faster, in that order", I deem this slowdown acceptable for now. I suspect but have not confirmed that a big slowdown comes from calling keywords twice in the file templates, once to test the existence of output and again to actually list the output. If so, a simple speedup might be to improve the templating engine to cache keywords when called more than once on the same revision. TODO: I found a bug while working on this. The following stack traces: hg log -r . -T '{ifcontains(phase, "secret public", "lol", "omg")}\n'
2014-10-04 03:48:56 +04:00
$ hg --color=debug --debug log > log.out
$ hg --color=debug --debug log --style default > style.out
$ cmp log.out style.out || diff -u log.out style.out
template-phases: do not show description or summary if empty This is a copy of 942d64e0a1ee, but applied to the phases template, which is itself almost a copy of the default template. Perhaps we should rewrite these templates to use the %include syntax afforded by config files. This change seems a bit too big for stable, though.
2015-04-24 21:52:12 +03:00
$ hg --color=debug --debug log -T phases > phases.out
$ cmp log.out phases.out || diff -u log.out phases.out
log: rewrite default template to use labels (issue2866) This is a complete rewrite of the default template to use labels. This seems ultimately useless to me in most cases. The biggest benefit of this patch to me seems to be a fairly complicated example of the templating engine. It was a lot of hard work to figure out the precise acceptable syntax, since it's almost undocumented. Hat tip to Steve Losh's smartlog template, which helped me figure out a lot of the syntax. Hopefully later I can use the present default log template as an example for documenting the templating engine. A test is attached. My goal was to match the --color=debug output, which may differ slightly in newlines from the actual ANSI escape codes output. I consider this an acceptable invisible deviation. There seems to be a considerable slowdown with this rewrite. Before: $ time hg log -T default -r .~100::. > /dev/null real 0m0.882s user 0m0.812s sys 0m0.064s $ time hg log -T default -r .~100::. > /dev/null real 0m0.872s user 0m0.796s sys 0m0.068s $ time hg log -T default -r .~100::. > /dev/null real 0m0.917s user 0m0.836s sys 0m0.076s After: $ time hg log -T default -r .~100::. > /dev/null real 0m1.480s user 0m1.392s sys 0m0.072s $ time hg log -T default -r .~100::. > /dev/null real 0m1.500s user 0m1.400s sys 0m0.088s $ time hg log -T default -r .~100::. > /dev/null real 0m1.462s user 0m1.364s sys 0m0.092s Following the maxim, "make it work, profile, make it faster, in that order", I deem this slowdown acceptable for now. I suspect but have not confirmed that a big slowdown comes from calling keywords twice in the file templates, once to test the existence of output and again to actually list the output. If so, a simple speedup might be to improve the templating engine to cache keywords when called more than once on the same revision. TODO: I found a bug while working on this. The following stack traces: hg log -r . -T '{ifcontains(phase, "secret public", "lol", "omg")}\n'
2014-10-04 03:48:56 +04:00
$ mv $HGRCPATH-bak $HGRCPATH
test-command-template: add a short description of a temporary snippet This snippet was introduced by 942d64e0a1ee. Its purpose seems a bit obscure without historical context.
2015-04-24 21:17:14 +03:00
Remove commit with empty commit message, so as to not pollute further
tests.
templates-default: do not show description or summary if empty changeset_printer shows description only if ctx.description().strip() is not empty. The default template should do the same way.
2015-03-27 16:12:53 +03:00
$ hg --config extensions.strip= strip -q .
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
Revision with no copies (used to print a traceback):
$ hg tip -v --template '\n'
Compact style works:
templating: make -T much more flexible It can now accept styles and paths and references to settings in [templates].
2014-03-09 03:38:50 +04:00
$ hg log -Tcompact
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
8[tip] 95c24699272e 2020-01-01 10:01 +0000 test
third
7:-1 29114dbae42b 1970-01-12 13:46 +0000 user
second
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
6:5,4 d41e714fe50d 1970-01-18 08:40 +0000 person
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
merge
5:3 13207e5a10d9 1970-01-18 08:40 +0000 person
new head
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
4 bbe44766e73d 1970-01-17 04:53 +0000 person
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
new branch
3 10e46f2dcbf4 1970-01-16 01:06 +0000 person
no user, no domain
2 97054abb4ab8 1970-01-14 21:20 +0000 other
no person
1 b608e9d1a3f0 1970-01-13 17:33 +0000 other
other 1
0 1e4e1b8f71e0 1970-01-12 13:46 +0000 user
line 1
$ hg log -v --style compact
8[tip] 95c24699272e 2020-01-01 10:01 +0000 test
third
7:-1 29114dbae42b 1970-01-12 13:46 +0000 User Name <user@hostname>
second
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
6:5,4 d41e714fe50d 1970-01-18 08:40 +0000 person
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
merge
5:3 13207e5a10d9 1970-01-18 08:40 +0000 person
new head
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
4 bbe44766e73d 1970-01-17 04:53 +0000 person
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
new branch
3 10e46f2dcbf4 1970-01-16 01:06 +0000 person
no user, no domain
2 97054abb4ab8 1970-01-14 21:20 +0000 other@place
no person
1 b608e9d1a3f0 1970-01-13 17:33 +0000 A. N. Other <other@place>
other 1
other 2
other 3
0 1e4e1b8f71e0 1970-01-12 13:46 +0000 User Name <user@hostname>
line 1
line 2
$ hg log --debug --style compact
8[tip]:7,-1 95c24699272e 2020-01-01 10:01 +0000 test
third
7:-1,-1 29114dbae42b 1970-01-12 13:46 +0000 User Name <user@hostname>
second
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
6:5,4 d41e714fe50d 1970-01-18 08:40 +0000 person
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
merge
5:3,-1 13207e5a10d9 1970-01-18 08:40 +0000 person
new head
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
4:3,-1 bbe44766e73d 1970-01-17 04:53 +0000 person
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
new branch
3:2,-1 10e46f2dcbf4 1970-01-16 01:06 +0000 person
no user, no domain
2:1,-1 97054abb4ab8 1970-01-14 21:20 +0000 other@place
no person
1:0,-1 b608e9d1a3f0 1970-01-13 17:33 +0000 A. N. Other <other@place>
other 1
other 2
other 3
0:-1,-1 1e4e1b8f71e0 1970-01-12 13:46 +0000 User Name <user@hostname>
line 1
line 2
Test xml styles:
templater: add new docheader/footer components for XML (issue4135) The existing header/footer components were templated per-changeset, and thus couldn't be correctly printed for an empty log
2015-08-27 00:27:14 +03:00
$ hg log --style xml -r 'not all()'
<?xml version="1.0"?>
<log>
</log>
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
$ hg log --style xml
<?xml version="1.0"?>
<log>
<logentry revision="8" node="95c24699272ef57d062b8bccc32c878bf841784a">
<tag>tip</tag>
<author email="test">test</author>
<date>2020-01-01T10:01:00+00:00</date>
<msg xml:space="preserve">third</msg>
</logentry>
<logentry revision="7" node="29114dbae42b9f078cf2714dbe3a86bba8ec7453">
<parent revision="-1" node="0000000000000000000000000000000000000000" />
<author email="user@hostname">User Name</author>
<date>1970-01-12T13:46:40+00:00</date>
<msg xml:space="preserve">second</msg>
</logentry>
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
<logentry revision="6" node="d41e714fe50d9e4a5f11b4d595d543481b5f980b">
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
<parent revision="5" node="13207e5a10d9fd28ec424934298e176197f2c67f" />
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
<parent revision="4" node="bbe44766e73d5f11ed2177f1838de10c53ef3e74" />
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
<author email="person">person</author>
<date>1970-01-18T08:40:01+00:00</date>
<msg xml:space="preserve">merge</msg>
</logentry>
<logentry revision="5" node="13207e5a10d9fd28ec424934298e176197f2c67f">
<parent revision="3" node="10e46f2dcbf4823578cf180f33ecf0b957964c47" />
<author email="person">person</author>
<date>1970-01-18T08:40:00+00:00</date>
<msg xml:space="preserve">new head</msg>
</logentry>
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
<logentry revision="4" node="bbe44766e73d5f11ed2177f1838de10c53ef3e74">
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
<branch>foo</branch>
<author email="person">person</author>
<date>1970-01-17T04:53:20+00:00</date>
<msg xml:space="preserve">new branch</msg>
</logentry>
<logentry revision="3" node="10e46f2dcbf4823578cf180f33ecf0b957964c47">
<author email="person">person</author>
<date>1970-01-16T01:06:40+00:00</date>
<msg xml:space="preserve">no user, no domain</msg>
</logentry>
<logentry revision="2" node="97054abb4ab824450e9164180baf491ae0078465">
<author email="other@place">other</author>
<date>1970-01-14T21:20:00+00:00</date>
<msg xml:space="preserve">no person</msg>
</logentry>
<logentry revision="1" node="b608e9d1a3f0273ccf70fb85fd6866b3482bf965">
<author email="other@place">A. N. Other</author>
<date>1970-01-13T17:33:20+00:00</date>
<msg xml:space="preserve">other 1
other 2
other 3</msg>
</logentry>
<logentry revision="0" node="1e4e1b8f71e05681d422154f5421e385fec3454f">
<author email="user@hostname">User Name</author>
<date>1970-01-12T13:46:40+00:00</date>
<msg xml:space="preserve">line 1
line 2</msg>
</logentry>
</log>
$ hg log -v --style xml
<?xml version="1.0"?>
<log>
<logentry revision="8" node="95c24699272ef57d062b8bccc32c878bf841784a">
<tag>tip</tag>
<author email="test">test</author>
<date>2020-01-01T10:01:00+00:00</date>
<msg xml:space="preserve">third</msg>
<paths>
<path action="A">fourth</path>
<path action="A">third</path>
<path action="R">second</path>
</paths>
<copies>
<copy source="second">fourth</copy>
</copies>
</logentry>
<logentry revision="7" node="29114dbae42b9f078cf2714dbe3a86bba8ec7453">
<parent revision="-1" node="0000000000000000000000000000000000000000" />
<author email="user@hostname">User Name</author>
<date>1970-01-12T13:46:40+00:00</date>
<msg xml:space="preserve">second</msg>
<paths>
<path action="A">second</path>
</paths>
</logentry>
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
<logentry revision="6" node="d41e714fe50d9e4a5f11b4d595d543481b5f980b">
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
<parent revision="5" node="13207e5a10d9fd28ec424934298e176197f2c67f" />
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
<parent revision="4" node="bbe44766e73d5f11ed2177f1838de10c53ef3e74" />
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
<author email="person">person</author>
<date>1970-01-18T08:40:01+00:00</date>
<msg xml:space="preserve">merge</msg>
<paths>
</paths>
</logentry>
<logentry revision="5" node="13207e5a10d9fd28ec424934298e176197f2c67f">
<parent revision="3" node="10e46f2dcbf4823578cf180f33ecf0b957964c47" />
<author email="person">person</author>
<date>1970-01-18T08:40:00+00:00</date>
<msg xml:space="preserve">new head</msg>
<paths>
<path action="A">d</path>
</paths>
</logentry>
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
<logentry revision="4" node="bbe44766e73d5f11ed2177f1838de10c53ef3e74">
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
<branch>foo</branch>
<author email="person">person</author>
<date>1970-01-17T04:53:20+00:00</date>
<msg xml:space="preserve">new branch</msg>
<paths>
</paths>
</logentry>
<logentry revision="3" node="10e46f2dcbf4823578cf180f33ecf0b957964c47">
<author email="person">person</author>
<date>1970-01-16T01:06:40+00:00</date>
<msg xml:space="preserve">no user, no domain</msg>
<paths>
<path action="M">c</path>
</paths>
</logentry>
<logentry revision="2" node="97054abb4ab824450e9164180baf491ae0078465">
<author email="other@place">other</author>
<date>1970-01-14T21:20:00+00:00</date>
<msg xml:space="preserve">no person</msg>
<paths>
<path action="A">c</path>
</paths>
</logentry>
<logentry revision="1" node="b608e9d1a3f0273ccf70fb85fd6866b3482bf965">
<author email="other@place">A. N. Other</author>
<date>1970-01-13T17:33:20+00:00</date>
<msg xml:space="preserve">other 1
other 2
other 3</msg>
<paths>
<path action="A">b</path>
</paths>
</logentry>
<logentry revision="0" node="1e4e1b8f71e05681d422154f5421e385fec3454f">
<author email="user@hostname">User Name</author>
<date>1970-01-12T13:46:40+00:00</date>
<msg xml:space="preserve">line 1
line 2</msg>
<paths>
<path action="A">a</path>
</paths>
</logentry>
</log>
$ hg log --debug --style xml
<?xml version="1.0"?>
<log>
<logentry revision="8" node="95c24699272ef57d062b8bccc32c878bf841784a">
<tag>tip</tag>
<parent revision="7" node="29114dbae42b9f078cf2714dbe3a86bba8ec7453" />
<parent revision="-1" node="0000000000000000000000000000000000000000" />
<author email="test">test</author>
<date>2020-01-01T10:01:00+00:00</date>
<msg xml:space="preserve">third</msg>
<paths>
<path action="A">fourth</path>
<path action="A">third</path>
<path action="R">second</path>
</paths>
<copies>
<copy source="second">fourth</copy>
</copies>
<extra key="branch">default</extra>
</logentry>
<logentry revision="7" node="29114dbae42b9f078cf2714dbe3a86bba8ec7453">
<parent revision="-1" node="0000000000000000000000000000000000000000" />
<parent revision="-1" node="0000000000000000000000000000000000000000" />
<author email="user@hostname">User Name</author>
<date>1970-01-12T13:46:40+00:00</date>
<msg xml:space="preserve">second</msg>
<paths>
<path action="A">second</path>
</paths>
<extra key="branch">default</extra>
</logentry>
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
<logentry revision="6" node="d41e714fe50d9e4a5f11b4d595d543481b5f980b">
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
<parent revision="5" node="13207e5a10d9fd28ec424934298e176197f2c67f" />
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
<parent revision="4" node="bbe44766e73d5f11ed2177f1838de10c53ef3e74" />
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
<author email="person">person</author>
<date>1970-01-18T08:40:01+00:00</date>
<msg xml:space="preserve">merge</msg>
<paths>
</paths>
<extra key="branch">default</extra>
</logentry>
<logentry revision="5" node="13207e5a10d9fd28ec424934298e176197f2c67f">
<parent revision="3" node="10e46f2dcbf4823578cf180f33ecf0b957964c47" />
<parent revision="-1" node="0000000000000000000000000000000000000000" />
<author email="person">person</author>
<date>1970-01-18T08:40:00+00:00</date>
<msg xml:space="preserve">new head</msg>
<paths>
<path action="A">d</path>
</paths>
<extra key="branch">default</extra>
</logentry>
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
<logentry revision="4" node="bbe44766e73d5f11ed2177f1838de10c53ef3e74">
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
<branch>foo</branch>
<parent revision="3" node="10e46f2dcbf4823578cf180f33ecf0b957964c47" />
<parent revision="-1" node="0000000000000000000000000000000000000000" />
<author email="person">person</author>
<date>1970-01-17T04:53:20+00:00</date>
<msg xml:space="preserve">new branch</msg>
<paths>
</paths>
<extra key="branch">foo</extra>
</logentry>
<logentry revision="3" node="10e46f2dcbf4823578cf180f33ecf0b957964c47">
<parent revision="2" node="97054abb4ab824450e9164180baf491ae0078465" />
<parent revision="-1" node="0000000000000000000000000000000000000000" />
<author email="person">person</author>
<date>1970-01-16T01:06:40+00:00</date>
<msg xml:space="preserve">no user, no domain</msg>
<paths>
<path action="M">c</path>
</paths>
<extra key="branch">default</extra>
</logentry>
<logentry revision="2" node="97054abb4ab824450e9164180baf491ae0078465">
<parent revision="1" node="b608e9d1a3f0273ccf70fb85fd6866b3482bf965" />
<parent revision="-1" node="0000000000000000000000000000000000000000" />
<author email="other@place">other</author>
<date>1970-01-14T21:20:00+00:00</date>
<msg xml:space="preserve">no person</msg>
<paths>
<path action="A">c</path>
</paths>
<extra key="branch">default</extra>
</logentry>
<logentry revision="1" node="b608e9d1a3f0273ccf70fb85fd6866b3482bf965">
<parent revision="0" node="1e4e1b8f71e05681d422154f5421e385fec3454f" />
<parent revision="-1" node="0000000000000000000000000000000000000000" />
<author email="other@place">A. N. Other</author>
<date>1970-01-13T17:33:20+00:00</date>
<msg xml:space="preserve">other 1
other 2
other 3</msg>
<paths>
<path action="A">b</path>
</paths>
<extra key="branch">default</extra>
</logentry>
<logentry revision="0" node="1e4e1b8f71e05681d422154f5421e385fec3454f">
<parent revision="-1" node="0000000000000000000000000000000000000000" />
<parent revision="-1" node="0000000000000000000000000000000000000000" />
<author email="user@hostname">User Name</author>
<date>1970-01-12T13:46:40+00:00</date>
<msg xml:space="preserve">line 1
line 2</msg>
<paths>
<path action="A">a</path>
</paths>
<extra key="branch">default</extra>
</logentry>
</log>
cmdutil: add json style to log-like commands Sadly, this can't be done with the normal templater like we do with XML due to JSON's inter-record comma rules.
2014-09-15 22:11:13 +04:00
Test JSON style:
$ hg log -k nosuch -Tjson
[]
$ hg log -qr . -Tjson
[
{
"rev": 8,
"node": "95c24699272ef57d062b8bccc32c878bf841784a"
}
]
$ hg log -vpr . -Tjson --stat
[
{
"rev": 8,
"node": "95c24699272ef57d062b8bccc32c878bf841784a",
"branch": "default",
"phase": "draft",
"user": "test",
"date": [1577872860, 0],
"desc": "third",
"bookmarks": [],
"tags": ["tip"],
"parents": ["29114dbae42b9f078cf2714dbe3a86bba8ec7453"],
"files": ["fourth", "second", "third"],
"diffstat": " fourth | 1 +\n second | 1 -\n third | 1 +\n 3 files changed, 2 insertions(+), 1 deletions(-)\n",
"diff": "diff -r 29114dbae42b -r 95c24699272e fourth\n--- /dev/null\tThu Jan 01 00:00:00 1970 +0000\n+++ b/fourth\tWed Jan 01 10:01:00 2020 +0000\n@@ -0,0 +1,1 @@\n+second\ndiff -r 29114dbae42b -r 95c24699272e second\n--- a/second\tMon Jan 12 13:46:40 1970 +0000\n+++ /dev/null\tThu Jan 01 00:00:00 1970 +0000\n@@ -1,1 +0,0 @@\n-second\ndiff -r 29114dbae42b -r 95c24699272e third\n--- /dev/null\tThu Jan 01 00:00:00 1970 +0000\n+++ b/third\tWed Jan 01 10:01:00 2020 +0000\n@@ -0,0 +1,1 @@\n+third\n"
}
]
jsonchangeset: don't honor whitespace and format-changing diffopts JSON is meant to be parsed by computers, and format changes can break them.
2014-11-19 09:13:05 +03:00
honor --git but not format-breaking diffopts
$ hg --config diff.noprefix=True log --git -vpr . -Tjson
[
{
"rev": 8,
"node": "95c24699272ef57d062b8bccc32c878bf841784a",
"branch": "default",
"phase": "draft",
"user": "test",
"date": [1577872860, 0],
"desc": "third",
"bookmarks": [],
"tags": ["tip"],
"parents": ["29114dbae42b9f078cf2714dbe3a86bba8ec7453"],
"files": ["fourth", "second", "third"],
"diff": "diff --git a/second b/fourth\nrename from second\nrename to fourth\ndiff --git a/third b/third\nnew file mode 100644\n--- /dev/null\n+++ b/third\n@@ -0,0 +1,1 @@\n+third\n"
}
]
cmdutil: add json style to log-like commands Sadly, this can't be done with the normal templater like we do with XML due to JSON's inter-record comma rules.
2014-09-15 22:11:13 +04:00
$ hg log -T json
[
{
"rev": 8,
"node": "95c24699272ef57d062b8bccc32c878bf841784a",
"branch": "default",
"phase": "draft",
"user": "test",
"date": [1577872860, 0],
"desc": "third",
"bookmarks": [],
"tags": ["tip"],
"parents": ["29114dbae42b9f078cf2714dbe3a86bba8ec7453"]
},
{
"rev": 7,
"node": "29114dbae42b9f078cf2714dbe3a86bba8ec7453",
"branch": "default",
"phase": "draft",
"user": "User Name <user@hostname>",
"date": [1000000, 0],
"desc": "second",
"bookmarks": [],
"tags": [],
"parents": ["0000000000000000000000000000000000000000"]
},
{
"rev": 6,
"node": "d41e714fe50d9e4a5f11b4d595d543481b5f980b",
"branch": "default",
"phase": "draft",
"user": "person",
"date": [1500001, 0],
"desc": "merge",
"bookmarks": [],
"tags": [],
"parents": ["13207e5a10d9fd28ec424934298e176197f2c67f", "bbe44766e73d5f11ed2177f1838de10c53ef3e74"]
},
{
"rev": 5,
"node": "13207e5a10d9fd28ec424934298e176197f2c67f",
"branch": "default",
"phase": "draft",
"user": "person",
"date": [1500000, 0],
"desc": "new head",
"bookmarks": [],
"tags": [],
"parents": ["10e46f2dcbf4823578cf180f33ecf0b957964c47"]
},
{
"rev": 4,
"node": "bbe44766e73d5f11ed2177f1838de10c53ef3e74",
"branch": "foo",
"phase": "draft",
"user": "person",
"date": [1400000, 0],
"desc": "new branch",
"bookmarks": [],
"tags": [],
"parents": ["10e46f2dcbf4823578cf180f33ecf0b957964c47"]
},
{
"rev": 3,
"node": "10e46f2dcbf4823578cf180f33ecf0b957964c47",
"branch": "default",
"phase": "draft",
"user": "person",
"date": [1300000, 0],
"desc": "no user, no domain",
"bookmarks": [],
"tags": [],
"parents": ["97054abb4ab824450e9164180baf491ae0078465"]
},
{
"rev": 2,
"node": "97054abb4ab824450e9164180baf491ae0078465",
"branch": "default",
"phase": "draft",
"user": "other@place",
"date": [1200000, 0],
"desc": "no person",
"bookmarks": [],
"tags": [],
"parents": ["b608e9d1a3f0273ccf70fb85fd6866b3482bf965"]
},
{
"rev": 1,
"node": "b608e9d1a3f0273ccf70fb85fd6866b3482bf965",
"branch": "default",
"phase": "draft",
"user": "A. N. Other <other@place>",
"date": [1100000, 0],
"desc": "other 1\nother 2\n\nother 3",
"bookmarks": [],
"tags": [],
"parents": ["1e4e1b8f71e05681d422154f5421e385fec3454f"]
},
{
"rev": 0,
"node": "1e4e1b8f71e05681d422154f5421e385fec3454f",
"branch": "default",
"phase": "draft",
"user": "User Name <user@hostname>",
"date": [1000000, 0],
"desc": "line 1\nline 2",
"bookmarks": [],
"tags": [],
"parents": ["0000000000000000000000000000000000000000"]
}
]
$ hg heads -v -Tjson
[
{
"rev": 8,
"node": "95c24699272ef57d062b8bccc32c878bf841784a",
"branch": "default",
"phase": "draft",
"user": "test",
"date": [1577872860, 0],
"desc": "third",
"bookmarks": [],
"tags": ["tip"],
"parents": ["29114dbae42b9f078cf2714dbe3a86bba8ec7453"],
"files": ["fourth", "second", "third"]
},
{
"rev": 6,
"node": "d41e714fe50d9e4a5f11b4d595d543481b5f980b",
"branch": "default",
"phase": "draft",
"user": "person",
"date": [1500001, 0],
"desc": "merge",
"bookmarks": [],
"tags": [],
"parents": ["13207e5a10d9fd28ec424934298e176197f2c67f", "bbe44766e73d5f11ed2177f1838de10c53ef3e74"],
"files": []
},
{
"rev": 4,
"node": "bbe44766e73d5f11ed2177f1838de10c53ef3e74",
"branch": "foo",
"phase": "draft",
"user": "person",
"date": [1400000, 0],
"desc": "new branch",
"bookmarks": [],
"tags": [],
"parents": ["10e46f2dcbf4823578cf180f33ecf0b957964c47"],
"files": []
}
]
$ hg log --debug -Tjson
[
{
"rev": 8,
"node": "95c24699272ef57d062b8bccc32c878bf841784a",
"branch": "default",
"phase": "draft",
"user": "test",
"date": [1577872860, 0],
"desc": "third",
"bookmarks": [],
"tags": ["tip"],
"parents": ["29114dbae42b9f078cf2714dbe3a86bba8ec7453"],
"manifest": "94961b75a2da554b4df6fb599e5bfc7d48de0c64",
"extra": {"branch": "default"},
"modified": [],
cmdutil.jsonchangeset: properly compute added and removed files jsonchangeset._show() was computing the reverse status of the current changeset. As a result, added files were showing up as removed and removed files were showing up as adds. There were existing tests for this code and they were flat out wrong.
2015-01-06 09:18:55 +03:00
"added": ["fourth", "third"],
"removed": ["second"]
cmdutil: add json style to log-like commands Sadly, this can't be done with the normal templater like we do with XML due to JSON's inter-record comma rules.
2014-09-15 22:11:13 +04:00
},
{
"rev": 7,
"node": "29114dbae42b9f078cf2714dbe3a86bba8ec7453",
"branch": "default",
"phase": "draft",
"user": "User Name <user@hostname>",
"date": [1000000, 0],
"desc": "second",
"bookmarks": [],
"tags": [],
"parents": ["0000000000000000000000000000000000000000"],
"manifest": "f2dbc354b94e5ec0b4f10680ee0cee816101d0bf",
"extra": {"branch": "default"},
"modified": [],
cmdutil.jsonchangeset: properly compute added and removed files jsonchangeset._show() was computing the reverse status of the current changeset. As a result, added files were showing up as removed and removed files were showing up as adds. There were existing tests for this code and they were flat out wrong.
2015-01-06 09:18:55 +03:00
"added": ["second"],
"removed": []
cmdutil: add json style to log-like commands Sadly, this can't be done with the normal templater like we do with XML due to JSON's inter-record comma rules.
2014-09-15 22:11:13 +04:00
},
{
"rev": 6,
"node": "d41e714fe50d9e4a5f11b4d595d543481b5f980b",
"branch": "default",
"phase": "draft",
"user": "person",
"date": [1500001, 0],
"desc": "merge",
"bookmarks": [],
"tags": [],
"parents": ["13207e5a10d9fd28ec424934298e176197f2c67f", "bbe44766e73d5f11ed2177f1838de10c53ef3e74"],
"manifest": "4dc3def4f9b4c6e8de820f6ee74737f91e96a216",
"extra": {"branch": "default"},
"modified": [],
"added": [],
"removed": []
},
{
"rev": 5,
"node": "13207e5a10d9fd28ec424934298e176197f2c67f",
"branch": "default",
"phase": "draft",
"user": "person",
"date": [1500000, 0],
"desc": "new head",
"bookmarks": [],
"tags": [],
"parents": ["10e46f2dcbf4823578cf180f33ecf0b957964c47"],
"manifest": "4dc3def4f9b4c6e8de820f6ee74737f91e96a216",
"extra": {"branch": "default"},
"modified": [],
cmdutil.jsonchangeset: properly compute added and removed files jsonchangeset._show() was computing the reverse status of the current changeset. As a result, added files were showing up as removed and removed files were showing up as adds. There were existing tests for this code and they were flat out wrong.
2015-01-06 09:18:55 +03:00
"added": ["d"],
"removed": []
cmdutil: add json style to log-like commands Sadly, this can't be done with the normal templater like we do with XML due to JSON's inter-record comma rules.
2014-09-15 22:11:13 +04:00
},
{
"rev": 4,
"node": "bbe44766e73d5f11ed2177f1838de10c53ef3e74",
"branch": "foo",
"phase": "draft",
"user": "person",
"date": [1400000, 0],
"desc": "new branch",
"bookmarks": [],
"tags": [],
"parents": ["10e46f2dcbf4823578cf180f33ecf0b957964c47"],
"manifest": "cb5a1327723bada42f117e4c55a303246eaf9ccc",
"extra": {"branch": "foo"},
"modified": [],
"added": [],
"removed": []
},
{
"rev": 3,
"node": "10e46f2dcbf4823578cf180f33ecf0b957964c47",
"branch": "default",
"phase": "draft",
"user": "person",
"date": [1300000, 0],
"desc": "no user, no domain",
"bookmarks": [],
"tags": [],
"parents": ["97054abb4ab824450e9164180baf491ae0078465"],
"manifest": "cb5a1327723bada42f117e4c55a303246eaf9ccc",
"extra": {"branch": "default"},
"modified": ["c"],
"added": [],
"removed": []
},
{
"rev": 2,
"node": "97054abb4ab824450e9164180baf491ae0078465",
"branch": "default",
"phase": "draft",
"user": "other@place",
"date": [1200000, 0],
"desc": "no person",
"bookmarks": [],
"tags": [],
"parents": ["b608e9d1a3f0273ccf70fb85fd6866b3482bf965"],
"manifest": "6e0e82995c35d0d57a52aca8da4e56139e06b4b1",
"extra": {"branch": "default"},
"modified": [],
cmdutil.jsonchangeset: properly compute added and removed files jsonchangeset._show() was computing the reverse status of the current changeset. As a result, added files were showing up as removed and removed files were showing up as adds. There were existing tests for this code and they were flat out wrong.
2015-01-06 09:18:55 +03:00
"added": ["c"],
"removed": []
cmdutil: add json style to log-like commands Sadly, this can't be done with the normal templater like we do with XML due to JSON's inter-record comma rules.
2014-09-15 22:11:13 +04:00
},
{
"rev": 1,
"node": "b608e9d1a3f0273ccf70fb85fd6866b3482bf965",
"branch": "default",
"phase": "draft",
"user": "A. N. Other <other@place>",
"date": [1100000, 0],
"desc": "other 1\nother 2\n\nother 3",
"bookmarks": [],
"tags": [],
"parents": ["1e4e1b8f71e05681d422154f5421e385fec3454f"],
"manifest": "4e8d705b1e53e3f9375e0e60dc7b525d8211fe55",
"extra": {"branch": "default"},
"modified": [],
cmdutil.jsonchangeset: properly compute added and removed files jsonchangeset._show() was computing the reverse status of the current changeset. As a result, added files were showing up as removed and removed files were showing up as adds. There were existing tests for this code and they were flat out wrong.
2015-01-06 09:18:55 +03:00
"added": ["b"],
"removed": []
cmdutil: add json style to log-like commands Sadly, this can't be done with the normal templater like we do with XML due to JSON's inter-record comma rules.
2014-09-15 22:11:13 +04:00
},
{
"rev": 0,
"node": "1e4e1b8f71e05681d422154f5421e385fec3454f",
"branch": "default",
"phase": "draft",
"user": "User Name <user@hostname>",
"date": [1000000, 0],
"desc": "line 1\nline 2",
"bookmarks": [],
"tags": [],
"parents": ["0000000000000000000000000000000000000000"],
"manifest": "a0c8bcbbb45c63b90b70ad007bf38961f64f2af0",
"extra": {"branch": "default"},
"modified": [],
cmdutil.jsonchangeset: properly compute added and removed files jsonchangeset._show() was computing the reverse status of the current changeset. As a result, added files were showing up as removed and removed files were showing up as adds. There were existing tests for this code and they were flat out wrong.
2015-01-06 09:18:55 +03:00
"added": ["a"],
"removed": []
cmdutil: add json style to log-like commands Sadly, this can't be done with the normal templater like we do with XML due to JSON's inter-record comma rules.
2014-09-15 22:11:13 +04:00
}
]
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
Error if style not readable:
tests: skip tests that require not having root (issue4089) This adds a new root hghave to test against. Almost all of these are a subset of unix-permissions, but that is also used for checking exec bit handling.
2013-11-15 04:07:43 +04:00
#if unix-permissions no-root
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
$ touch q
$ chmod 0 q
$ hg log --style ./q
abort: Permission denied: ./q
tests: add exit codes to unified tests
2010-09-17 02:51:32 +04:00
[255]
test-command-template: enable for Windows
2012-06-11 21:18:36 +04:00
#endif
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
Error if no style:
$ hg log --style notexist
templater: fix output instability from gsoc patches
2013-05-03 05:41:22 +04:00
abort: style 'notexist' not found
log: add a status template It appears that git users like having a --name-status option on `git log`. There exist at least three questions on StackOverflow on how to do this for hg. The desired output is not difficult to build with templates, and since this is something that svn users might also want, it seems desirable to have this as another standard template. This mimics the output of `hg status` and adds it to the log output. It also follows status's convention of displaying copies with a -C option. Brief example: $ hg log -T status -C changeset: 24883:7d1b9b7ac9fd bookmark: statustemplate tag: tip parent: 24864:a08f05e3a9cf user: Jordi Gutiérrez Hermoso <jordigh@octave.org> date: Wed Apr 22 14:05:04 2015 -0400 summary: log: add a status template files: A added A copied original M modified R removed Of course, everything is also coloured correctly, and there are tests to prove it.
2015-05-10 21:04:43 +03:00
(available styles: bisect, changelog, compact, default, phases, status, xml)
tests: add exit codes to unified tests
2010-09-17 02:51:32 +04:00
[255]
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
templates: re-add template listing support We used to have --style nosuch to list templates, but --style is now merged with --template/-T where random strings are acceptable templates. So we reserve 'list' to allow listing templates.
2014-07-26 00:35:09 +04:00
$ hg log -T list
log: add a status template It appears that git users like having a --name-status option on `git log`. There exist at least three questions on StackOverflow on how to do this for hg. The desired output is not difficult to build with templates, and since this is something that svn users might also want, it seems desirable to have this as another standard template. This mimics the output of `hg status` and adds it to the log output. It also follows status's convention of displaying copies with a -C option. Brief example: $ hg log -T status -C changeset: 24883:7d1b9b7ac9fd bookmark: statustemplate tag: tip parent: 24864:a08f05e3a9cf user: Jordi Gutiérrez Hermoso <jordigh@octave.org> date: Wed Apr 22 14:05:04 2015 -0400 summary: log: add a status template files: A added A copied original M modified R removed Of course, everything is also coloured correctly, and there are tests to prove it.
2015-05-10 21:04:43 +03:00
available styles: bisect, changelog, compact, default, phases, status, xml
templates: re-add template listing support We used to have --style nosuch to list templates, but --style is now merged with --template/-T where random strings are acceptable templates. So we reserve 'list' to allow listing templates.
2014-07-26 00:35:09 +04:00
abort: specify a template
[255]
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
Error if style missing key:
$ echo 'q = q' > t
$ hg log --style ./t
templater: give slightly nicer error for unknown map entries
2010-12-20 21:09:00 +03:00
abort: "changeset" not in template map
tests: add exit codes to unified tests
2010-09-17 02:51:32 +04:00
[255]
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
templater: handle a missing value correctly Before, using a broken style such as: changeset = would result in a traceback. This fixes a regression introduced in 47618355ffc8.
2012-08-04 16:37:17 +04:00
Error if style missing value:
$ echo 'changeset =' > t
$ hg log --style t
templater: do not abuse SyntaxError to report errors in template map file SyntaxError is the class representing syntax errors in Python code. We should use a dedicated exception class for our needs. With this change, unnecessary re-wrapping of SyntaxError can be eliminated.
2016-03-26 12:01:04 +03:00
hg: parse error at t:1: missing value
templater: handle a missing value correctly Before, using a broken style such as: changeset = would result in a traceback. This fixes a regression introduced in 47618355ffc8.
2012-08-04 16:37:17 +04:00
[255]
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
Error if include fails:
$ echo 'changeset = q' >> t
tests: skip tests that require not having root (issue4089) This adds a new root hghave to test against. Almost all of these are a subset of unix-permissions, but that is also used for checking exec bit handling.
2013-11-15 04:07:43 +04:00
#if unix-permissions no-root
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
$ hg log --style ./t
abort: template file ./q: Permission denied
tests: add exit codes to unified tests
2010-09-17 02:51:32 +04:00
[255]
tests: remove protected file forcibly for portability Before this patch, test-command-template.t is timed out on Solaris, because "rm" on permission denied file implies prompting "override protection 0 (yes/no)?" and blocks execution of test script.
2016-02-05 16:32:05 +03:00
$ rm -f q
test-command-template: enable for Windows
2012-06-11 21:18:36 +04:00
#endif
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
Include works:
$ echo '{rev}' > q
$ hg log --style ./t
8
7
6
5
4
3
2
1
0
templater: abort if infinite recursion detected while evaluation (issue4758) It would be nice if we could detect recursion at the parsing phase, but we can't because a template can refer to a keyword of the same name. For example, "rev = {rev}" is valid if rev is a keyword, and we don't know if rev is a keyword or a template while parsing.
2015-07-22 17:29:41 +03:00
Check that recursive reference does not fall into RuntimeError (issue4758):
common mistake:
$ hg log -T '{changeset}\n'
abort: recursive reference 'changeset' in template
[255]
circular reference:
$ cat << EOF > issue4758
> changeset = '{foo}'
> foo = '{changeset}'
> EOF
$ hg log --style ./issue4758
abort: recursive reference 'foo' in template
[255]
templater: abort if infinite recursion detected while compiling In this case, a template is parsed recursively with no thunk for lazy evaluation. This patch prevents recursion by putting a dummy of the same name into a cache that will be referenced while parsing if there's a recursion. changeset = {files % changeset}\n ~~~~~~~~~ = [(_runrecursivesymbol, 'changeset')]
2015-07-23 17:41:29 +03:00
buildmap() -> gettemplate(), where no thunk was made:
$ hg log -T '{files % changeset}\n'
abort: recursive reference 'changeset' in template
[255]
templater: abort if infinite recursion detected while evaluation (issue4758) It would be nice if we could detect recursion at the parsing phase, but we can't because a template can refer to a keyword of the same name. For example, "rev = {rev}" is valid if rev is a keyword, and we don't know if rev is a keyword or a template while parsing.
2015-07-22 17:29:41 +03:00
not a recursion if a keyword of the same name exists:
$ cat << EOF > issue4758
> changeset = '{tags % rev}'
> rev = '{rev} {tag}\n'
> EOF
$ hg log --style ./issue4758 -r tip
8 tip
templater: set the correct phase for parents Akin to b5baef1e39f6 which did this for `hg log`, the following sets the correct phase for the {phase} keyword when the context is a parent of the current cset. This allows templates such as the following to be defined, parent = '{label("log.parent changeset.{phase}", "parent: {rev}:{node|formatnode}")}\n' which when called on a parent (e.g. with the `parents` template keyword), will produce the correct phase.
2014-10-04 06:03:31 +04:00
Check that {phase} works correctly on parents:
$ cat << EOF > parentphase
> changeset_debug = '{rev} ({phase}):{parents}\n'
> parent = ' {rev} ({phase})'
> EOF
$ hg phase -r 5 --public
$ hg phase -r 7 --secret --force
$ hg log --debug -G --style ./parentphase
@ 8 (secret): 7 (secret) -1 (public)
|
o 7 (secret): -1 (public) -1 (public)
o 6 (draft): 5 (public) 4 (draft)
|\
| o 5 (public): 3 (public) -1 (public)
| |
o | 4 (draft): 3 (public) -1 (public)
|/
o 3 (public): 2 (public) -1 (public)
|
o 2 (public): 1 (public) -1 (public)
|
o 1 (public): 0 (public) -1 (public)
|
o 0 (public): -1 (public) -1 (public)
templater: support using templates with non-standard names from map file Allow to add arbitrarily-named entries to a template map file and then reference them, to make it possible to deduplicate and simplify templates code.
2013-09-22 13:52:18 +04:00
Missing non-standard names give no error (backward compatibility):
$ echo "changeset = '{c}'" > t
$ hg log --style ./t
Defining non-standard name works:
$ cat <<EOF > t
> changeset = '{c}'
> c = q
> EOF
$ hg log --style ./t
8
7
6
5
4
3
2
1
0
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
ui.style works:
$ echo '[ui]' > .hg/hgrc
$ echo 'style = t' >> .hg/hgrc
$ hg log
8
7
6
5
4
3
2
1
0
Issue338:
$ hg log --style=changelog > changelog
$ cat changelog
2020-01-01 test <test>
* fourth, second, third:
third
[95c24699272e] [tip]
1970-01-12 User Name <user@hostname>
* second:
second
[29114dbae42b]
1970-01-18 person <person>
* merge
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
[d41e714fe50d]
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
* d:
new head
[13207e5a10d9]
1970-01-17 person <person>
* new branch
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
[bbe44766e73d] <foo>
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
1970-01-16 person <person>
* c:
no user, no domain
[10e46f2dcbf4]
1970-01-14 other <other@place>
* c:
no person
[97054abb4ab8]
1970-01-13 A. N. Other <other@place>
* b:
other 1 other 2
other 3
[b608e9d1a3f0]
1970-01-12 User Name <user@hostname>
* a:
line 1 line 2
[1e4e1b8f71e0]
tests: added a short description to issue numbers Many tests already had a short line to describe what IssueXXX is about. I find that quite useful when reading a test.
2010-09-24 12:13:49 +04:00
Issue2130: xml output for 'hg heads' is malformed
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
$ hg heads --style changelog
2020-01-01 test <test>
* fourth, second, third:
third
[95c24699272e] [tip]
1970-01-18 person <person>
* merge
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
[d41e714fe50d]
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
1970-01-17 person <person>
* new branch
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
[bbe44766e73d] <foo>
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
Keys work:
template: add showbranch template for {branch} Like showbranches, but always yields exactly one branch. Replaces the less correct {branches|nonempty}.
2010-12-13 18:30:15 +03:00
$ for key in author branch branches date desc file_adds file_dels file_mods \
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
> file_copies file_copies_switch files \
templatekw: add p1rev, p1node, p2rev, p2node keywords The {parents} template is cumbersome for some uses, as it does not show anything if there's only one "natural" parent and you can't use it to get the full 40 digit node hashes for parents unless you rely on the behavior of the --debug flag. Introduce four new template keywords: {p1rev}, {p2rev}, {p1node} and {p2node}. The "node" flavors of these always show full 40 digit hashes, but users can get the short version with a filter construction like '{p1node|short}'.
2012-07-10 19:43:32 +04:00
> manifest node parents rev tags diffstat extras \
> p1rev p2rev p1node p2node; do
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
> for mode in '' --verbose --debug; do
> hg log $mode --template "$key$mode: {$key}\n"
> done
> done
author: test
author: User Name <user@hostname>
author: person
author: person
author: person
author: person
author: other@place
author: A. N. Other <other@place>
author: User Name <user@hostname>
author--verbose: test
author--verbose: User Name <user@hostname>
author--verbose: person
author--verbose: person
author--verbose: person
author--verbose: person
author--verbose: other@place
author--verbose: A. N. Other <other@place>
author--verbose: User Name <user@hostname>
author--debug: test
author--debug: User Name <user@hostname>
author--debug: person
author--debug: person
author--debug: person
author--debug: person
author--debug: other@place
author--debug: A. N. Other <other@place>
author--debug: User Name <user@hostname>
template: add showbranch template for {branch} Like showbranches, but always yields exactly one branch. Replaces the less correct {branches|nonempty}.
2010-12-13 18:30:15 +03:00
branch: default
branch: default
branch: default
branch: default
branch: foo
branch: default
branch: default
branch: default
branch: default
branch--verbose: default
branch--verbose: default
branch--verbose: default
branch--verbose: default
branch--verbose: foo
branch--verbose: default
branch--verbose: default
branch--verbose: default
branch--verbose: default
branch--debug: default
branch--debug: default
branch--debug: default
branch--debug: default
branch--debug: foo
branch--debug: default
branch--debug: default
branch--debug: default
branch--debug: default
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
branches:
branches:
branches:
branches:
branches: foo
branches:
branches:
branches:
branches:
branches--verbose:
branches--verbose:
branches--verbose:
branches--verbose:
branches--verbose: foo
branches--verbose:
branches--verbose:
branches--verbose:
branches--verbose:
branches--debug:
branches--debug:
branches--debug:
branches--debug:
branches--debug: foo
branches--debug:
branches--debug:
branches--debug:
branches--debug:
date: 1577872860.00
date: 1000000.00
date: 1500001.00
date: 1500000.00
date: 1400000.00
date: 1300000.00
date: 1200000.00
date: 1100000.00
date: 1000000.00
date--verbose: 1577872860.00
date--verbose: 1000000.00
date--verbose: 1500001.00
date--verbose: 1500000.00
date--verbose: 1400000.00
date--verbose: 1300000.00
date--verbose: 1200000.00
date--verbose: 1100000.00
date--verbose: 1000000.00
date--debug: 1577872860.00
date--debug: 1000000.00
date--debug: 1500001.00
date--debug: 1500000.00
date--debug: 1400000.00
date--debug: 1300000.00
date--debug: 1200000.00
date--debug: 1100000.00
date--debug: 1000000.00
desc: third
desc: second
desc: merge
desc: new head
desc: new branch
desc: no user, no domain
desc: no person
desc: other 1
other 2
other 3
desc: line 1
line 2
desc--verbose: third
desc--verbose: second
desc--verbose: merge
desc--verbose: new head
desc--verbose: new branch
desc--verbose: no user, no domain
desc--verbose: no person
desc--verbose: other 1
other 2
other 3
desc--verbose: line 1
line 2
desc--debug: third
desc--debug: second
desc--debug: merge
desc--debug: new head
desc--debug: new branch
desc--debug: no user, no domain
desc--debug: no person
desc--debug: other 1
other 2
other 3
desc--debug: line 1
line 2
file_adds: fourth third
file_adds: second
file_adds:
file_adds: d
file_adds:
file_adds:
file_adds: c
file_adds: b
file_adds: a
file_adds--verbose: fourth third
file_adds--verbose: second
file_adds--verbose:
file_adds--verbose: d
file_adds--verbose:
file_adds--verbose:
file_adds--verbose: c
file_adds--verbose: b
file_adds--verbose: a
file_adds--debug: fourth third
file_adds--debug: second
file_adds--debug:
file_adds--debug: d
file_adds--debug:
file_adds--debug:
file_adds--debug: c
file_adds--debug: b
file_adds--debug: a
file_dels: second
file_dels:
file_dels:
file_dels:
file_dels:
file_dels:
file_dels:
file_dels:
file_dels:
file_dels--verbose: second
file_dels--verbose:
file_dels--verbose:
file_dels--verbose:
file_dels--verbose:
file_dels--verbose:
file_dels--verbose:
file_dels--verbose:
file_dels--verbose:
file_dels--debug: second
file_dels--debug:
file_dels--debug:
file_dels--debug:
file_dels--debug:
file_dels--debug:
file_dels--debug:
file_dels--debug:
file_dels--debug:
file_mods:
file_mods:
file_mods:
file_mods:
file_mods:
file_mods: c
file_mods:
file_mods:
file_mods:
file_mods--verbose:
file_mods--verbose:
file_mods--verbose:
file_mods--verbose:
file_mods--verbose:
file_mods--verbose: c
file_mods--verbose:
file_mods--verbose:
file_mods--verbose:
file_mods--debug:
file_mods--debug:
file_mods--debug:
file_mods--debug:
file_mods--debug:
file_mods--debug: c
file_mods--debug:
file_mods--debug:
file_mods--debug:
file_copies: fourth (second)
file_copies:
file_copies:
file_copies:
file_copies:
file_copies:
file_copies:
file_copies:
file_copies:
file_copies--verbose: fourth (second)
file_copies--verbose:
file_copies--verbose:
file_copies--verbose:
file_copies--verbose:
file_copies--verbose:
file_copies--verbose:
file_copies--verbose:
file_copies--verbose:
file_copies--debug: fourth (second)
file_copies--debug:
file_copies--debug:
file_copies--debug:
file_copies--debug:
file_copies--debug:
file_copies--debug:
file_copies--debug:
file_copies--debug:
file_copies_switch:
file_copies_switch:
file_copies_switch:
file_copies_switch:
file_copies_switch:
file_copies_switch:
file_copies_switch:
file_copies_switch:
file_copies_switch:
file_copies_switch--verbose:
file_copies_switch--verbose:
file_copies_switch--verbose:
file_copies_switch--verbose:
file_copies_switch--verbose:
file_copies_switch--verbose:
file_copies_switch--verbose:
file_copies_switch--verbose:
file_copies_switch--verbose:
file_copies_switch--debug:
file_copies_switch--debug:
file_copies_switch--debug:
file_copies_switch--debug:
file_copies_switch--debug:
file_copies_switch--debug:
file_copies_switch--debug:
file_copies_switch--debug:
file_copies_switch--debug:
files: fourth second third
files: second
files:
files: d
files:
files: c
files: c
files: b
files: a
files--verbose: fourth second third
files--verbose: second
files--verbose:
files--verbose: d
files--verbose:
files--verbose: c
files--verbose: c
files--verbose: b
files--verbose: a
files--debug: fourth second third
files--debug: second
files--debug:
files--debug: d
files--debug:
files--debug: c
files--debug: c
files--debug: b
files--debug: a
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
manifest: 6:94961b75a2da
manifest: 5:f2dbc354b94e
manifest: 4:4dc3def4f9b4
manifest: 4:4dc3def4f9b4
manifest: 3:cb5a1327723b
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
manifest: 3:cb5a1327723b
manifest: 2:6e0e82995c35
manifest: 1:4e8d705b1e53
manifest: 0:a0c8bcbbb45c
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
manifest--verbose: 6:94961b75a2da
manifest--verbose: 5:f2dbc354b94e
manifest--verbose: 4:4dc3def4f9b4
manifest--verbose: 4:4dc3def4f9b4
manifest--verbose: 3:cb5a1327723b
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
manifest--verbose: 3:cb5a1327723b
manifest--verbose: 2:6e0e82995c35
manifest--verbose: 1:4e8d705b1e53
manifest--verbose: 0:a0c8bcbbb45c
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
manifest--debug: 6:94961b75a2da554b4df6fb599e5bfc7d48de0c64
manifest--debug: 5:f2dbc354b94e5ec0b4f10680ee0cee816101d0bf
manifest--debug: 4:4dc3def4f9b4c6e8de820f6ee74737f91e96a216
manifest--debug: 4:4dc3def4f9b4c6e8de820f6ee74737f91e96a216
manifest--debug: 3:cb5a1327723bada42f117e4c55a303246eaf9ccc
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
manifest--debug: 3:cb5a1327723bada42f117e4c55a303246eaf9ccc
manifest--debug: 2:6e0e82995c35d0d57a52aca8da4e56139e06b4b1
manifest--debug: 1:4e8d705b1e53e3f9375e0e60dc7b525d8211fe55
manifest--debug: 0:a0c8bcbbb45c63b90b70ad007bf38961f64f2af0
node: 95c24699272ef57d062b8bccc32c878bf841784a
node: 29114dbae42b9f078cf2714dbe3a86bba8ec7453
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
node: d41e714fe50d9e4a5f11b4d595d543481b5f980b
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
node: 13207e5a10d9fd28ec424934298e176197f2c67f
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
node: bbe44766e73d5f11ed2177f1838de10c53ef3e74
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
node: 10e46f2dcbf4823578cf180f33ecf0b957964c47
node: 97054abb4ab824450e9164180baf491ae0078465
node: b608e9d1a3f0273ccf70fb85fd6866b3482bf965
node: 1e4e1b8f71e05681d422154f5421e385fec3454f
node--verbose: 95c24699272ef57d062b8bccc32c878bf841784a
node--verbose: 29114dbae42b9f078cf2714dbe3a86bba8ec7453
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
node--verbose: d41e714fe50d9e4a5f11b4d595d543481b5f980b
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
node--verbose: 13207e5a10d9fd28ec424934298e176197f2c67f
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
node--verbose: bbe44766e73d5f11ed2177f1838de10c53ef3e74
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
node--verbose: 10e46f2dcbf4823578cf180f33ecf0b957964c47
node--verbose: 97054abb4ab824450e9164180baf491ae0078465
node--verbose: b608e9d1a3f0273ccf70fb85fd6866b3482bf965
node--verbose: 1e4e1b8f71e05681d422154f5421e385fec3454f
node--debug: 95c24699272ef57d062b8bccc32c878bf841784a
node--debug: 29114dbae42b9f078cf2714dbe3a86bba8ec7453
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
node--debug: d41e714fe50d9e4a5f11b4d595d543481b5f980b
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
node--debug: 13207e5a10d9fd28ec424934298e176197f2c67f
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
node--debug: bbe44766e73d5f11ed2177f1838de10c53ef3e74
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
node--debug: 10e46f2dcbf4823578cf180f33ecf0b957964c47
node--debug: 97054abb4ab824450e9164180baf491ae0078465
node--debug: b608e9d1a3f0273ccf70fb85fd6866b3482bf965
node--debug: 1e4e1b8f71e05681d422154f5421e385fec3454f
parents:
parents: -1:000000000000
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
parents: 5:13207e5a10d9 4:bbe44766e73d
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
parents: 3:10e46f2dcbf4
parents:
parents:
parents:
parents:
parents:
parents--verbose:
parents--verbose: -1:000000000000
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
parents--verbose: 5:13207e5a10d9 4:bbe44766e73d
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
parents--verbose: 3:10e46f2dcbf4
parents--verbose:
parents--verbose:
parents--verbose:
parents--verbose:
parents--verbose:
parents--debug: 7:29114dbae42b9f078cf2714dbe3a86bba8ec7453 -1:0000000000000000000000000000000000000000
parents--debug: -1:0000000000000000000000000000000000000000 -1:0000000000000000000000000000000000000000
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
parents--debug: 5:13207e5a10d9fd28ec424934298e176197f2c67f 4:bbe44766e73d5f11ed2177f1838de10c53ef3e74
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
parents--debug: 3:10e46f2dcbf4823578cf180f33ecf0b957964c47 -1:0000000000000000000000000000000000000000
parents--debug: 3:10e46f2dcbf4823578cf180f33ecf0b957964c47 -1:0000000000000000000000000000000000000000
parents--debug: 2:97054abb4ab824450e9164180baf491ae0078465 -1:0000000000000000000000000000000000000000
parents--debug: 1:b608e9d1a3f0273ccf70fb85fd6866b3482bf965 -1:0000000000000000000000000000000000000000
parents--debug: 0:1e4e1b8f71e05681d422154f5421e385fec3454f -1:0000000000000000000000000000000000000000
parents--debug: -1:0000000000000000000000000000000000000000 -1:0000000000000000000000000000000000000000
rev: 8
rev: 7
rev: 6
rev: 5
rev: 4
rev: 3
rev: 2
rev: 1
rev: 0
rev--verbose: 8
rev--verbose: 7
rev--verbose: 6
rev--verbose: 5
rev--verbose: 4
rev--verbose: 3
rev--verbose: 2
rev--verbose: 1
rev--verbose: 0
rev--debug: 8
rev--debug: 7
rev--debug: 6
rev--debug: 5
rev--debug: 4
rev--debug: 3
rev--debug: 2
rev--debug: 1
rev--debug: 0
tags: tip
tags:
tags:
tags:
tags:
tags:
tags:
tags:
tags:
tags--verbose: tip
tags--verbose:
tags--verbose:
tags--verbose:
tags--verbose:
tags--verbose:
tags--verbose:
tags--verbose:
tags--verbose:
tags--debug: tip
tags--debug:
tags--debug:
tags--debug:
tags--debug:
tags--debug:
tags--debug:
tags--debug:
tags--debug:
diffstat: 3: +2/-1
diffstat: 1: +1/-0
diffstat: 0: +0/-0
diffstat: 1: +1/-0
diffstat: 0: +0/-0
diffstat: 1: +1/-0
diffstat: 1: +4/-0
diffstat: 1: +2/-0
diffstat: 1: +1/-0
diffstat--verbose: 3: +2/-1
diffstat--verbose: 1: +1/-0
diffstat--verbose: 0: +0/-0
diffstat--verbose: 1: +1/-0
diffstat--verbose: 0: +0/-0
diffstat--verbose: 1: +1/-0
diffstat--verbose: 1: +4/-0
diffstat--verbose: 1: +2/-0
diffstat--verbose: 1: +1/-0
diffstat--debug: 3: +2/-1
diffstat--debug: 1: +1/-0
diffstat--debug: 0: +0/-0
diffstat--debug: 1: +1/-0
diffstat--debug: 0: +0/-0
diffstat--debug: 1: +1/-0
diffstat--debug: 1: +4/-0
diffstat--debug: 1: +2/-0
diffstat--debug: 1: +1/-0
extras: branch=default
extras: branch=default
extras: branch=default
extras: branch=default
extras: branch=foo
extras: branch=default
extras: branch=default
extras: branch=default
extras: branch=default
extras--verbose: branch=default
extras--verbose: branch=default
extras--verbose: branch=default
extras--verbose: branch=default
extras--verbose: branch=foo
extras--verbose: branch=default
extras--verbose: branch=default
extras--verbose: branch=default
extras--verbose: branch=default
extras--debug: branch=default
extras--debug: branch=default
extras--debug: branch=default
extras--debug: branch=default
extras--debug: branch=foo
extras--debug: branch=default
extras--debug: branch=default
extras--debug: branch=default
extras--debug: branch=default
templatekw: add p1rev, p1node, p2rev, p2node keywords The {parents} template is cumbersome for some uses, as it does not show anything if there's only one "natural" parent and you can't use it to get the full 40 digit node hashes for parents unless you rely on the behavior of the --debug flag. Introduce four new template keywords: {p1rev}, {p2rev}, {p1node} and {p2node}. The "node" flavors of these always show full 40 digit hashes, but users can get the short version with a filter construction like '{p1node|short}'.
2012-07-10 19:43:32 +04:00
p1rev: 7
p1rev: -1
p1rev: 5
p1rev: 3
p1rev: 3
p1rev: 2
p1rev: 1
p1rev: 0
p1rev: -1
p1rev--verbose: 7
p1rev--verbose: -1
p1rev--verbose: 5
p1rev--verbose: 3
p1rev--verbose: 3
p1rev--verbose: 2
p1rev--verbose: 1
p1rev--verbose: 0
p1rev--verbose: -1
p1rev--debug: 7
p1rev--debug: -1
p1rev--debug: 5
p1rev--debug: 3
p1rev--debug: 3
p1rev--debug: 2
p1rev--debug: 1
p1rev--debug: 0
p1rev--debug: -1
p2rev: -1
p2rev: -1
p2rev: 4
p2rev: -1
p2rev: -1
p2rev: -1
p2rev: -1
p2rev: -1
p2rev: -1
p2rev--verbose: -1
p2rev--verbose: -1
p2rev--verbose: 4
p2rev--verbose: -1
p2rev--verbose: -1
p2rev--verbose: -1
p2rev--verbose: -1
p2rev--verbose: -1
p2rev--verbose: -1
p2rev--debug: -1
p2rev--debug: -1
p2rev--debug: 4
p2rev--debug: -1
p2rev--debug: -1
p2rev--debug: -1
p2rev--debug: -1
p2rev--debug: -1
p2rev--debug: -1
p1node: 29114dbae42b9f078cf2714dbe3a86bba8ec7453
p1node: 0000000000000000000000000000000000000000
p1node: 13207e5a10d9fd28ec424934298e176197f2c67f
p1node: 10e46f2dcbf4823578cf180f33ecf0b957964c47
p1node: 10e46f2dcbf4823578cf180f33ecf0b957964c47
p1node: 97054abb4ab824450e9164180baf491ae0078465
p1node: b608e9d1a3f0273ccf70fb85fd6866b3482bf965
p1node: 1e4e1b8f71e05681d422154f5421e385fec3454f
p1node: 0000000000000000000000000000000000000000
p1node--verbose: 29114dbae42b9f078cf2714dbe3a86bba8ec7453
p1node--verbose: 0000000000000000000000000000000000000000
p1node--verbose: 13207e5a10d9fd28ec424934298e176197f2c67f
p1node--verbose: 10e46f2dcbf4823578cf180f33ecf0b957964c47
p1node--verbose: 10e46f2dcbf4823578cf180f33ecf0b957964c47
p1node--verbose: 97054abb4ab824450e9164180baf491ae0078465
p1node--verbose: b608e9d1a3f0273ccf70fb85fd6866b3482bf965
p1node--verbose: 1e4e1b8f71e05681d422154f5421e385fec3454f
p1node--verbose: 0000000000000000000000000000000000000000
p1node--debug: 29114dbae42b9f078cf2714dbe3a86bba8ec7453
p1node--debug: 0000000000000000000000000000000000000000
p1node--debug: 13207e5a10d9fd28ec424934298e176197f2c67f
p1node--debug: 10e46f2dcbf4823578cf180f33ecf0b957964c47
p1node--debug: 10e46f2dcbf4823578cf180f33ecf0b957964c47
p1node--debug: 97054abb4ab824450e9164180baf491ae0078465
p1node--debug: b608e9d1a3f0273ccf70fb85fd6866b3482bf965
p1node--debug: 1e4e1b8f71e05681d422154f5421e385fec3454f
p1node--debug: 0000000000000000000000000000000000000000
p2node: 0000000000000000000000000000000000000000
p2node: 0000000000000000000000000000000000000000
p2node: bbe44766e73d5f11ed2177f1838de10c53ef3e74
p2node: 0000000000000000000000000000000000000000
p2node: 0000000000000000000000000000000000000000
p2node: 0000000000000000000000000000000000000000
p2node: 0000000000000000000000000000000000000000
p2node: 0000000000000000000000000000000000000000
p2node: 0000000000000000000000000000000000000000
p2node--verbose: 0000000000000000000000000000000000000000
p2node--verbose: 0000000000000000000000000000000000000000
p2node--verbose: bbe44766e73d5f11ed2177f1838de10c53ef3e74
p2node--verbose: 0000000000000000000000000000000000000000
p2node--verbose: 0000000000000000000000000000000000000000
p2node--verbose: 0000000000000000000000000000000000000000
p2node--verbose: 0000000000000000000000000000000000000000
p2node--verbose: 0000000000000000000000000000000000000000
p2node--verbose: 0000000000000000000000000000000000000000
p2node--debug: 0000000000000000000000000000000000000000
p2node--debug: 0000000000000000000000000000000000000000
p2node--debug: bbe44766e73d5f11ed2177f1838de10c53ef3e74
p2node--debug: 0000000000000000000000000000000000000000
p2node--debug: 0000000000000000000000000000000000000000
p2node--debug: 0000000000000000000000000000000000000000
p2node--debug: 0000000000000000000000000000000000000000
p2node--debug: 0000000000000000000000000000000000000000
p2node--debug: 0000000000000000000000000000000000000000
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
Filters work:
$ hg log --template '{author|domain}\n'
hostname
place
place
hostname
$ hg log --template '{author|person}\n'
test
User Name
person
person
person
person
other
A. N. Other
User Name
$ hg log --template '{author|user}\n'
test
user
person
person
person
person
other
other
user
$ hg log --template '{date|date}\n'
Wed Jan 01 10:01:00 2020 +0000
Mon Jan 12 13:46:40 1970 +0000
Sun Jan 18 08:40:01 1970 +0000
Sun Jan 18 08:40:00 1970 +0000
Sat Jan 17 04:53:20 1970 +0000
Fri Jan 16 01:06:40 1970 +0000
Wed Jan 14 21:20:00 1970 +0000
Tue Jan 13 17:33:20 1970 +0000
Mon Jan 12 13:46:40 1970 +0000
$ hg log --template '{date|isodate}\n'
2020-01-01 10:01 +0000
1970-01-12 13:46 +0000
1970-01-18 08:40 +0000
1970-01-18 08:40 +0000
1970-01-17 04:53 +0000
1970-01-16 01:06 +0000
1970-01-14 21:20 +0000
1970-01-13 17:33 +0000
1970-01-12 13:46 +0000
$ hg log --template '{date|isodatesec}\n'
2020-01-01 10:01:00 +0000
1970-01-12 13:46:40 +0000
1970-01-18 08:40:01 +0000
1970-01-18 08:40:00 +0000
1970-01-17 04:53:20 +0000
1970-01-16 01:06:40 +0000
1970-01-14 21:20:00 +0000
1970-01-13 17:33:20 +0000
1970-01-12 13:46:40 +0000
$ hg log --template '{date|rfc822date}\n'
Wed, 01 Jan 2020 10:01:00 +0000
Mon, 12 Jan 1970 13:46:40 +0000
Sun, 18 Jan 1970 08:40:01 +0000
Sun, 18 Jan 1970 08:40:00 +0000
Sat, 17 Jan 1970 04:53:20 +0000
Fri, 16 Jan 1970 01:06:40 +0000
Wed, 14 Jan 1970 21:20:00 +0000
Tue, 13 Jan 1970 17:33:20 +0000
Mon, 12 Jan 1970 13:46:40 +0000
$ hg log --template '{desc|firstline}\n'
third
second
merge
new head
new branch
no user, no domain
no person
other 1
line 1
$ hg log --template '{node|short}\n'
95c24699272e
29114dbae42b
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
d41e714fe50d
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
13207e5a10d9
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
bbe44766e73d
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
10e46f2dcbf4
97054abb4ab8
b608e9d1a3f0
1e4e1b8f71e0
$ hg log --template '<changeset author="{author|xmlescape}"/>\n'
<changeset author="test"/>
<changeset author="User Name &lt;user@hostname&gt;"/>
<changeset author="person"/>
<changeset author="person"/>
<changeset author="person"/>
<changeset author="person"/>
<changeset author="other@place"/>
<changeset author="A. N. Other &lt;other@place&gt;"/>
<changeset author="User Name &lt;user@hostname&gt;"/>
$ hg log --template '{rev}: {children}\n'
8:
7: 8:95c24699272e
6:
localrepo: reuse parent manifest in commitctx if no files have changed This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
2011-05-02 21:20:29 +04:00
5: 6:d41e714fe50d
4: 6:d41e714fe50d
3: 4:bbe44766e73d 5:13207e5a10d9
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
2: 3:10e46f2dcbf4
1: 2:97054abb4ab8
0: 1:b608e9d1a3f0
Formatnode filter works:
$ hg -q log -r 0 --template '{node|formatnode}\n'
1e4e1b8f71e0
$ hg log -r 0 --template '{node|formatnode}\n'
1e4e1b8f71e0
$ hg -v log -r 0 --template '{node|formatnode}\n'
1e4e1b8f71e0
$ hg --debug log -r 0 --template '{node|formatnode}\n'
1e4e1b8f71e05681d422154f5421e385fec3454f
tests: make {date|age} template output independent of the current date
2012-01-11 18:18:20 +04:00
Age filter:
tests: fix hidden repeatability problem with age filter test This test was corrupting later cases in mysterious ways because the hash of the changeset was changing every day at midnight. This made it hard to figure out why tests were consistently breaking after they were consistently working.
2015-05-12 20:33:42 +03:00
$ hg init unstable-hash
$ cd unstable-hash
tests: make {date|age} template output independent of the current date
2012-01-11 18:18:20 +04:00
$ hg log --template '{date|age}\n' > /dev/null || exit 1
test-command-template.t: make "age" filter test work on Feb 29th reported by Julien Cristau.
2013-01-02 16:59:07 +04:00
>>> from datetime import datetime, timedelta
tests: make {date|age} template output independent of the current date
2012-01-11 18:18:20 +04:00
>>> fp = open('a', 'w')
test-command-template.t: make "age" filter test work on Feb 29th reported by Julien Cristau.
2013-01-02 16:59:07 +04:00
>>> n = datetime.now() + timedelta(366 * 7)
>>> fp.write('%d-%d-%d 00:00' % (n.year, n.month, n.day))
tests: make {date|age} template output independent of the current date
2012-01-11 18:18:20 +04:00
>>> fp.close()
$ hg add a
$ hg commit -m future -d "`cat a`"
check-code: fix check for trailing whitespace on sh command lines The $ has been without necessary escaping since introduced in c4ecbbd282fe.
2012-08-08 20:10:16 +04:00
$ hg log -l1 --template '{date|age}\n'
tests: make {date|age} template output independent of the current date
2012-01-11 18:18:20 +04:00
7 years from now
tests: fix hidden repeatability problem with age filter test This test was corrupting later cases in mysterious ways because the hash of the changeset was changing every day at midnight. This made it hard to figure out why tests were consistently breaking after they were consistently working.
2015-05-12 20:33:42 +03:00
$ cd ..
$ rm -rf unstable-hash
Add a dummy commit to make up for the instability of the above:
$ echo a > a
$ hg add a
$ hg ci -m future
templater: add count template filter, plus tests Previously there was no way of telling how much children or bookmarks or tags a certain changeset has in a template. It was possible to tell if a changeset has either 0 or not 0 bookmarks, but not to tell if it has 1 or 2 of them, for example. This filter, simply named count, makes it possible to count the number of items in a list or the length of a string (or, anything that python's len can count). E.g.: {children|count}, {bookmarks|count}, {file_adds|count}. Testing the filter on node hash and shortened node hash is chosen because they both have defined length. As for lists of strings - children, tags and file_adds are used, because they provide some variety and also prove that what's counted is the number of string items in the list, and not the list stringified (they are lists of non-empty, multi-character strings). Additionally, revset template function is used for testing the filter, since the combination is very flexible and will possibly be used together a lot. (The previous version of this patch had an incorrect email subject and was apparently lost - patchwork says the patch has been accepted, but it's not so. The changes between that and this patch are minimal: now the filter does not disturb the alphabetical order of function definitions and dict keys.)
2014-09-09 17:14:13 +04:00
Count filter:
$ hg log -l1 --template '{node|count} {node|short|count}\n'
40 12
$ hg log -l1 --template '{revset("null^")|count} {revset(".")|count} {revset("0::3")|count}\n'
0 1 4
$ hg log -G --template '{rev}: children: {children|count}, \
> tags: {tags|count}, file_adds: {file_adds|count}, \
> ancestors: {revset("ancestors(%s)", rev)|count}'
@ 9: children: 0, tags: 1, file_adds: 1, ancestors: 3
|
o 8: children: 1, tags: 0, file_adds: 2, ancestors: 2
|
o 7: children: 1, tags: 0, file_adds: 1, ancestors: 1
o 6: children: 0, tags: 0, file_adds: 0, ancestors: 7
|\
| o 5: children: 1, tags: 0, file_adds: 1, ancestors: 5
| |
o | 4: children: 1, tags: 0, file_adds: 0, ancestors: 5
|/
o 3: children: 2, tags: 0, file_adds: 0, ancestors: 4
|
o 2: children: 1, tags: 0, file_adds: 1, ancestors: 3
|
o 1: children: 1, tags: 0, file_adds: 1, ancestors: 2
|
o 0: children: 1, tags: 0, file_adds: 1, ancestors: 1
templatefilters: add "upper" and "lower" for case conversion Typically it will be used in patchbomb's flag template, which will be implemented by future patches.
2015-03-30 17:54:29 +03:00
Upper/lower filters:
$ hg log -r0 --template '{branch|upper}\n'
DEFAULT
$ hg log -r0 --template '{author|lower}\n'
user name <user@hostname>
$ hg log -r0 --template '{date|upper}\n'
abort: template filter 'upper' is not compatible with keyword 'date'
[255]
tests: add a new commit to test-commandline-template This commit modifies, adds, renames, removes files all at once. It will be mostly interesting for an upcoming test relating to the status log template.
2015-05-05 21:45:09 +03:00
Add a commit that does all possible modifications at once
$ echo modify >> third
$ touch b
$ hg add b
$ hg mv fourth fifth
$ hg rm a
$ hg ci -m "Modify, add, remove, rename"
log: add a status template It appears that git users like having a --name-status option on `git log`. There exist at least three questions on StackOverflow on how to do this for hg. The desired output is not difficult to build with templates, and since this is something that svn users might also want, it seems desirable to have this as another standard template. This mimics the output of `hg status` and adds it to the log output. It also follows status's convention of displaying copies with a -C option. Brief example: $ hg log -T status -C changeset: 24883:7d1b9b7ac9fd bookmark: statustemplate tag: tip parent: 24864:a08f05e3a9cf user: Jordi Gutiérrez Hermoso <jordigh@octave.org> date: Wed Apr 22 14:05:04 2015 -0400 summary: log: add a status template files: A added A copied original M modified R removed Of course, everything is also coloured correctly, and there are tests to prove it.
2015-05-10 21:04:43 +03:00
Check the status template
$ cat <<EOF >> $HGRCPATH
> [extensions]
> color=
> EOF
$ hg log -T status -r 10
changeset: 10:0f9759ec227a
tag: tip
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: Modify, add, remove, rename
files:
M third
A b
A fifth
R a
R fourth
$ hg log -T status -C -r 10
changeset: 10:0f9759ec227a
tag: tip
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: Modify, add, remove, rename
files:
M third
A b
A fifth
fourth
R a
R fourth
$ hg log -T status -C -r 10 -v
changeset: 10:0f9759ec227a
tag: tip
user: test
date: Thu Jan 01 00:00:00 1970 +0000
description:
Modify, add, remove, rename
files:
M third
A b
A fifth
fourth
R a
R fourth
$ hg log -T status -C -r 10 --debug
changeset: 10:0f9759ec227a4859c2014a345cd8a859022b7c6c
tag: tip
phase: secret
parent: 9:bf9dfba36635106d6a73ccc01e28b762da60e066
parent: -1:0000000000000000000000000000000000000000
manifest: 8:89dd546f2de0a9d6d664f58d86097eb97baba567
user: test
date: Thu Jan 01 00:00:00 1970 +0000
extra: branch=default
description:
Modify, add, remove, rename
files:
M third
A b
A fifth
fourth
R a
R fourth
$ hg log -T status -C -r 10 --quiet
10:0f9759ec227a
$ hg --color=debug log -T status -r 10
[log.changeset changeset.secret|changeset: 10:0f9759ec227a]
[log.tag|tag: tip]
[log.user|user: test]
[log.date|date: Thu Jan 01 00:00:00 1970 +0000]
[log.summary|summary: Modify, add, remove, rename]
[ui.note log.files|files:]
[status.modified|M third]
[status.added|A b]
[status.added|A fifth]
[status.removed|R a]
[status.removed|R fourth]
$ hg --color=debug log -T status -C -r 10
[log.changeset changeset.secret|changeset: 10:0f9759ec227a]
[log.tag|tag: tip]
[log.user|user: test]
[log.date|date: Thu Jan 01 00:00:00 1970 +0000]
[log.summary|summary: Modify, add, remove, rename]
[ui.note log.files|files:]
[status.modified|M third]
[status.added|A b]
[status.added|A fifth]
[status.copied| fourth]
[status.removed|R a]
[status.removed|R fourth]
$ hg --color=debug log -T status -C -r 10 -v
[log.changeset changeset.secret|changeset: 10:0f9759ec227a]
[log.tag|tag: tip]
[log.user|user: test]
[log.date|date: Thu Jan 01 00:00:00 1970 +0000]
[ui.note log.description|description:]
[ui.note log.description|Modify, add, remove, rename]
[ui.note log.files|files:]
[status.modified|M third]
[status.added|A b]
[status.added|A fifth]
[status.copied| fourth]
[status.removed|R a]
[status.removed|R fourth]
$ hg --color=debug log -T status -C -r 10 --debug
[log.changeset changeset.secret|changeset: 10:0f9759ec227a4859c2014a345cd8a859022b7c6c]
[log.tag|tag: tip]
[log.phase|phase: secret]
[log.parent changeset.secret|parent: 9:bf9dfba36635106d6a73ccc01e28b762da60e066]
[log.parent changeset.public|parent: -1:0000000000000000000000000000000000000000]
[ui.debug log.manifest|manifest: 8:89dd546f2de0a9d6d664f58d86097eb97baba567]
[log.user|user: test]
[log.date|date: Thu Jan 01 00:00:00 1970 +0000]
[ui.debug log.extra|extra: branch=default]
[ui.note log.description|description:]
[ui.note log.description|Modify, add, remove, rename]
[ui.note log.files|files:]
[status.modified|M third]
[status.added|A b]
[status.added|A fifth]
[status.copied| fourth]
[status.removed|R a]
[status.removed|R fourth]
$ hg --color=debug log -T status -C -r 10 --quiet
[log.node|10:0f9759ec227a]
map-cmdline.bisect: rewrite to just %include the default template This also adds labels to the output, as the tests now show. I took the liberty to give two labels to the bisection status, just like revisions get the log.changeset and changeset.phase statuses.
2015-05-10 20:48:10 +03:00
Check the bisect template
$ hg bisect -g 1
$ hg bisect -b 3 --noupdate
Testing changeset 2:97054abb4ab8 (2 changesets remaining, ~1 tests)
$ hg log -T bisect -r 0:4
changeset: 0:1e4e1b8f71e0
bisect: good (implicit)
user: User Name <user@hostname>
date: Mon Jan 12 13:46:40 1970 +0000
summary: line 1
changeset: 1:b608e9d1a3f0
bisect: good
user: A. N. Other <other@place>
date: Tue Jan 13 17:33:20 1970 +0000
summary: other 1
changeset: 2:97054abb4ab8
bisect: untested
user: other@place
date: Wed Jan 14 21:20:00 1970 +0000
summary: no person
changeset: 3:10e46f2dcbf4
bisect: bad
user: person
date: Fri Jan 16 01:06:40 1970 +0000
summary: no user, no domain
changeset: 4:bbe44766e73d
bisect: bad (implicit)
branch: foo
user: person
date: Sat Jan 17 04:53:20 1970 +0000
summary: new branch
$ hg log --debug -T bisect -r 0:4
changeset: 0:1e4e1b8f71e05681d422154f5421e385fec3454f
bisect: good (implicit)
phase: public
parent: -1:0000000000000000000000000000000000000000
parent: -1:0000000000000000000000000000000000000000
manifest: 0:a0c8bcbbb45c63b90b70ad007bf38961f64f2af0
user: User Name <user@hostname>
date: Mon Jan 12 13:46:40 1970 +0000
files+: a
extra: branch=default
description:
line 1
line 2
changeset: 1:b608e9d1a3f0273ccf70fb85fd6866b3482bf965
bisect: good
phase: public
parent: 0:1e4e1b8f71e05681d422154f5421e385fec3454f
parent: -1:0000000000000000000000000000000000000000
manifest: 1:4e8d705b1e53e3f9375e0e60dc7b525d8211fe55
user: A. N. Other <other@place>
date: Tue Jan 13 17:33:20 1970 +0000
files+: b
extra: branch=default
description:
other 1
other 2
other 3
changeset: 2:97054abb4ab824450e9164180baf491ae0078465
bisect: untested
phase: public
parent: 1:b608e9d1a3f0273ccf70fb85fd6866b3482bf965
parent: -1:0000000000000000000000000000000000000000
manifest: 2:6e0e82995c35d0d57a52aca8da4e56139e06b4b1
user: other@place
date: Wed Jan 14 21:20:00 1970 +0000
files+: c
extra: branch=default
description:
no person
changeset: 3:10e46f2dcbf4823578cf180f33ecf0b957964c47
bisect: bad
phase: public
parent: 2:97054abb4ab824450e9164180baf491ae0078465
parent: -1:0000000000000000000000000000000000000000
manifest: 3:cb5a1327723bada42f117e4c55a303246eaf9ccc
user: person
date: Fri Jan 16 01:06:40 1970 +0000
files: c
extra: branch=default
description:
no user, no domain
changeset: 4:bbe44766e73d5f11ed2177f1838de10c53ef3e74
bisect: bad (implicit)
branch: foo
phase: draft
parent: 3:10e46f2dcbf4823578cf180f33ecf0b957964c47
parent: -1:0000000000000000000000000000000000000000
manifest: 3:cb5a1327723bada42f117e4c55a303246eaf9ccc
user: person
date: Sat Jan 17 04:53:20 1970 +0000
extra: branch=foo
description:
new branch
$ hg log -v -T bisect -r 0:4
changeset: 0:1e4e1b8f71e0
bisect: good (implicit)
user: User Name <user@hostname>
date: Mon Jan 12 13:46:40 1970 +0000
files: a
description:
line 1
line 2
changeset: 1:b608e9d1a3f0
bisect: good
user: A. N. Other <other@place>
date: Tue Jan 13 17:33:20 1970 +0000
files: b
description:
other 1
other 2
other 3
changeset: 2:97054abb4ab8
bisect: untested
user: other@place
date: Wed Jan 14 21:20:00 1970 +0000
files: c
description:
no person
changeset: 3:10e46f2dcbf4
bisect: bad
user: person
date: Fri Jan 16 01:06:40 1970 +0000
files: c
description:
no user, no domain
changeset: 4:bbe44766e73d
bisect: bad (implicit)
branch: foo
user: person
date: Sat Jan 17 04:53:20 1970 +0000
description:
new branch
$ hg --color=debug log -T bisect -r 0:4
[log.changeset changeset.public|changeset: 0:1e4e1b8f71e0]
[log.bisect bisect.good|bisect: good (implicit)]
[log.user|user: User Name <user@hostname>]
[log.date|date: Mon Jan 12 13:46:40 1970 +0000]
[log.summary|summary: line 1]
[log.changeset changeset.public|changeset: 1:b608e9d1a3f0]
[log.bisect bisect.good|bisect: good]
[log.user|user: A. N. Other <other@place>]
[log.date|date: Tue Jan 13 17:33:20 1970 +0000]
[log.summary|summary: other 1]
[log.changeset changeset.public|changeset: 2:97054abb4ab8]
[log.bisect bisect.untested|bisect: untested]
[log.user|user: other@place]
[log.date|date: Wed Jan 14 21:20:00 1970 +0000]
[log.summary|summary: no person]
[log.changeset changeset.public|changeset: 3:10e46f2dcbf4]
[log.bisect bisect.bad|bisect: bad]
[log.user|user: person]
[log.date|date: Fri Jan 16 01:06:40 1970 +0000]
[log.summary|summary: no user, no domain]
[log.changeset changeset.draft|changeset: 4:bbe44766e73d]
[log.bisect bisect.bad|bisect: bad (implicit)]
[log.branch|branch: foo]
[log.user|user: person]
[log.date|date: Sat Jan 17 04:53:20 1970 +0000]
[log.summary|summary: new branch]
$ hg --color=debug log --debug -T bisect -r 0:4
[log.changeset changeset.public|changeset: 0:1e4e1b8f71e05681d422154f5421e385fec3454f]
[log.bisect bisect.good|bisect: good (implicit)]
[log.phase|phase: public]
[log.parent changeset.public|parent: -1:0000000000000000000000000000000000000000]
[log.parent changeset.public|parent: -1:0000000000000000000000000000000000000000]
[ui.debug log.manifest|manifest: 0:a0c8bcbbb45c63b90b70ad007bf38961f64f2af0]
[log.user|user: User Name <user@hostname>]
[log.date|date: Mon Jan 12 13:46:40 1970 +0000]
[ui.debug log.files|files+: a]
[ui.debug log.extra|extra: branch=default]
[ui.note log.description|description:]
[ui.note log.description|line 1
line 2]
[log.changeset changeset.public|changeset: 1:b608e9d1a3f0273ccf70fb85fd6866b3482bf965]
[log.bisect bisect.good|bisect: good]
[log.phase|phase: public]
[log.parent changeset.public|parent: 0:1e4e1b8f71e05681d422154f5421e385fec3454f]
[log.parent changeset.public|parent: -1:0000000000000000000000000000000000000000]
[ui.debug log.manifest|manifest: 1:4e8d705b1e53e3f9375e0e60dc7b525d8211fe55]
[log.user|user: A. N. Other <other@place>]
[log.date|date: Tue Jan 13 17:33:20 1970 +0000]
[ui.debug log.files|files+: b]
[ui.debug log.extra|extra: branch=default]
[ui.note log.description|description:]
[ui.note log.description|other 1
other 2
other 3]
[log.changeset changeset.public|changeset: 2:97054abb4ab824450e9164180baf491ae0078465]
[log.bisect bisect.untested|bisect: untested]
[log.phase|phase: public]
[log.parent changeset.public|parent: 1:b608e9d1a3f0273ccf70fb85fd6866b3482bf965]
[log.parent changeset.public|parent: -1:0000000000000000000000000000000000000000]
[ui.debug log.manifest|manifest: 2:6e0e82995c35d0d57a52aca8da4e56139e06b4b1]
[log.user|user: other@place]
[log.date|date: Wed Jan 14 21:20:00 1970 +0000]
[ui.debug log.files|files+: c]
[ui.debug log.extra|extra: branch=default]
[ui.note log.description|description:]
[ui.note log.description|no person]
[log.changeset changeset.public|changeset: 3:10e46f2dcbf4823578cf180f33ecf0b957964c47]
[log.bisect bisect.bad|bisect: bad]
[log.phase|phase: public]
[log.parent changeset.public|parent: 2:97054abb4ab824450e9164180baf491ae0078465]
[log.parent changeset.public|parent: -1:0000000000000000000000000000000000000000]
[ui.debug log.manifest|manifest: 3:cb5a1327723bada42f117e4c55a303246eaf9ccc]
[log.user|user: person]
[log.date|date: Fri Jan 16 01:06:40 1970 +0000]
[ui.debug log.files|files: c]
[ui.debug log.extra|extra: branch=default]
[ui.note log.description|description:]
[ui.note log.description|no user, no domain]
[log.changeset changeset.draft|changeset: 4:bbe44766e73d5f11ed2177f1838de10c53ef3e74]
[log.bisect bisect.bad|bisect: bad (implicit)]
[log.branch|branch: foo]
[log.phase|phase: draft]
[log.parent changeset.public|parent: 3:10e46f2dcbf4823578cf180f33ecf0b957964c47]
[log.parent changeset.public|parent: -1:0000000000000000000000000000000000000000]
[ui.debug log.manifest|manifest: 3:cb5a1327723bada42f117e4c55a303246eaf9ccc]
[log.user|user: person]
[log.date|date: Sat Jan 17 04:53:20 1970 +0000]
[ui.debug log.extra|extra: branch=foo]
[ui.note log.description|description:]
[ui.note log.description|new branch]
$ hg --color=debug log -v -T bisect -r 0:4
[log.changeset changeset.public|changeset: 0:1e4e1b8f71e0]
[log.bisect bisect.good|bisect: good (implicit)]
[log.user|user: User Name <user@hostname>]
[log.date|date: Mon Jan 12 13:46:40 1970 +0000]
[ui.note log.files|files: a]
[ui.note log.description|description:]
[ui.note log.description|line 1
line 2]
[log.changeset changeset.public|changeset: 1:b608e9d1a3f0]
[log.bisect bisect.good|bisect: good]
[log.user|user: A. N. Other <other@place>]
[log.date|date: Tue Jan 13 17:33:20 1970 +0000]
[ui.note log.files|files: b]
[ui.note log.description|description:]
[ui.note log.description|other 1
other 2
other 3]
[log.changeset changeset.public|changeset: 2:97054abb4ab8]
[log.bisect bisect.untested|bisect: untested]
[log.user|user: other@place]
[log.date|date: Wed Jan 14 21:20:00 1970 +0000]
[ui.note log.files|files: c]
[ui.note log.description|description:]
[ui.note log.description|no person]
[log.changeset changeset.public|changeset: 3:10e46f2dcbf4]
[log.bisect bisect.bad|bisect: bad]
[log.user|user: person]
[log.date|date: Fri Jan 16 01:06:40 1970 +0000]
[ui.note log.files|files: c]
[ui.note log.description|description:]
[ui.note log.description|no user, no domain]
[log.changeset changeset.draft|changeset: 4:bbe44766e73d]
[log.bisect bisect.bad|bisect: bad (implicit)]
[log.branch|branch: foo]
[log.user|user: person]
[log.date|date: Sat Jan 17 04:53:20 1970 +0000]
[ui.note log.description|description:]
[ui.note log.description|new branch]
$ hg bisect --reset
log: add a status template It appears that git users like having a --name-status option on `git log`. There exist at least three questions on StackOverflow on how to do this for hg. The desired output is not difficult to build with templates, and since this is something that svn users might also want, it seems desirable to have this as another standard template. This mimics the output of `hg status` and adds it to the log output. It also follows status's convention of displaying copies with a -C option. Brief example: $ hg log -T status -C changeset: 24883:7d1b9b7ac9fd bookmark: statustemplate tag: tip parent: 24864:a08f05e3a9cf user: Jordi Gutiérrez Hermoso <jordigh@octave.org> date: Wed Apr 22 14:05:04 2015 -0400 summary: log: add a status template files: A added A copied original M modified R removed Of course, everything is also coloured correctly, and there are tests to prove it.
2015-05-10 21:04:43 +03:00
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
Error on syntax:
$ echo 'x = "f' >> t
$ hg log
templater: do not abuse SyntaxError to report errors in template map file SyntaxError is the class representing syntax errors in Python code. We should use a dedicated exception class for our needs. With this change, unnecessary re-wrapping of SyntaxError can be eliminated.
2016-03-26 12:01:04 +03:00
hg: parse error at t:3: unmatched quotes
tests: add exit codes to unified tests
2010-09-17 02:51:32 +04:00
[255]
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
templater: check existence of closing brace of template string
2015-06-15 17:03:30 +03:00
$ hg log -T '{date'
hg: parse error at 1: unterminated template expansion
[255]
templater: abort when a template filter raises an exception (issue2987)
2012-08-18 02:12:01 +04:00
Behind the scenes, this will throw TypeError
$ hg log -l 3 --template '{date|obfuscate}\n'
tests: fix template test output
2012-08-24 23:52:45 +04:00
abort: template filter 'obfuscate' is not compatible with keyword 'date'
templater: abort when a template filter raises an exception (issue2987)
2012-08-18 02:12:01 +04:00
[255]
Behind the scenes, this will throw a ValueError
$ hg log -l 3 --template 'line: {desc|shortdate}\n'
tests: fix template test output
2012-08-24 23:52:45 +04:00
abort: template filter 'shortdate' is not compatible with keyword 'desc'
templater: abort when a template filter raises an exception (issue2987)
2012-08-18 02:12:01 +04:00
[255]
Behind the scenes, this will throw AttributeError
$ hg log -l 3 --template 'line: {date|escape}\n'
tests: fix template test output
2012-08-24 23:52:45 +04:00
abort: template filter 'escape' is not compatible with keyword 'date'
templater: abort when a template filter raises an exception (issue2987)
2012-08-18 02:12:01 +04:00
[255]
templater: port localdate filter to a function It will be extended to accept a timezone argument.
2015-09-01 13:15:16 +03:00
$ hg log -l 3 --template 'line: {extras|localdate}\n'
hg: parse error: localdate expects a date information
[255]
templater: abort when a template filter raises an exception (issue2987)
2012-08-18 02:12:01 +04:00
Behind the scenes, this will throw ValueError
$ hg tip --template '{author|email|date}\n'
templatefilters: remove redundant 'date' and 'strip' filters These filters are defined as 'date()' and 'strip()' functions. Help messages are moved to the corresponding functions.
2015-07-04 10:07:42 +03:00
hg: parse error: date expects a date information
templater: abort when a template filter raises an exception (issue2987)
2012-08-18 02:12:01 +04:00
[255]
templater: introduce one-pass parsing of nested template strings Instead of re-parsing quoted strings as templates, the tokenizer can delegate the parsing of nested template strings to the parser. It has two benefits: 1. syntax errors can be reported with absolute positions 2. nested template can use quotes just like shell: "{"{rev}"}" It doesn't sound nice that the tokenizer recurses into the parser. We could instead make the tokenize itself recursive, but it would be much more complicated because we would have to adjust binding strengths carefully and put dummy infix operators to concatenate template fragments. Now "string" token without r"" never appears. It will be removed by the next patch.
2015-06-15 17:11:35 +03:00
Error in nested template:
$ hg log -T '{"date'
hg: parse error at 2: unterminated string
[255]
$ hg log -T '{"foo{date|=}"}'
hg: parse error at 11: syntax error
[255]
templater: raise error for unknown func Previously, if a template '{foo()}' was given, the buildfunc would not be able to match it and hit a code path that would not return so it would error out later in the templater stating that NoneType was not iterable. This patch makes sure that a proper error is raised so that the user can be informed. Tests have been updated.
2014-03-28 02:21:27 +04:00
Thrown an error if a template function doesn't exist
$ hg tip --template '{foo()}\n'
hg: parse error: unknown function 'foo'
[255]
templater: allow piping generator-type function output to filters Template functions use "yield"s assuming that the result will be combined into a string, which means both "f -> str" and "f -> generator" should behave in the same way. Before this patch, piping generator function resulted in a cryptic error. We had to insert "|stringify" in this case. $ hg log --template '{if(author, author)|user}\n' abort: template filter 'userfilter' is not compatible with keyword '[(<function runsymbol at 0x7f5af2e8d8c0>, 'author'), (<function runsymbol at 0x7f5af2e8d8c0>, 'author')]'
2015-02-23 18:04:55 +03:00
Pass generator object created by template function to filter
$ hg log -l 1 --template '{if(author, author)|user}\n'
test
templater: add "diff" template function "diff" allows to embed changes in the target revision into template output, even if the command itself doesn't take "--patch" option Combination of "[committemplate]" configuration and "diff" template function can achieve the feature like issue231 ("option to have diff displayed in commit editor buffer") http://bz.selenic.com/show_bug.cgi?id=231 For example, templating below can be used to add each "diff" output lines "HG: " prefix:: {splitlines(diff) % 'HG: {line}\n'} This patch implements "diff" not as "a template keyword" but as "a template function" to take include/exclude patterns at runtime. It allows to specify target files of command (by -I/-X command line options) and "diff" separately.
2014-08-28 17:45:36 +04:00
Test diff function:
$ hg diff -c 8
diff -r 29114dbae42b -r 95c24699272e fourth
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/fourth Wed Jan 01 10:01:00 2020 +0000
@@ -0,0 +1,1 @@
+second
diff -r 29114dbae42b -r 95c24699272e second
--- a/second Mon Jan 12 13:46:40 1970 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,1 +0,0 @@
-second
diff -r 29114dbae42b -r 95c24699272e third
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/third Wed Jan 01 10:01:00 2020 +0000
@@ -0,0 +1,1 @@
+third
$ hg log -r 8 -T "{diff()}"
diff -r 29114dbae42b -r 95c24699272e fourth
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/fourth Wed Jan 01 10:01:00 2020 +0000
@@ -0,0 +1,1 @@
+second
diff -r 29114dbae42b -r 95c24699272e second
--- a/second Mon Jan 12 13:46:40 1970 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,1 +0,0 @@
-second
diff -r 29114dbae42b -r 95c24699272e third
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/third Wed Jan 01 10:01:00 2020 +0000
@@ -0,0 +1,1 @@
+third
$ hg log -r 8 -T "{diff('glob:f*')}"
diff -r 29114dbae42b -r 95c24699272e fourth
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/fourth Wed Jan 01 10:01:00 2020 +0000
@@ -0,0 +1,1 @@
+second
$ hg log -r 8 -T "{diff('', 'glob:f*')}"
diff -r 29114dbae42b -r 95c24699272e second
--- a/second Mon Jan 12 13:46:40 1970 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,1 +0,0 @@
-second
diff -r 29114dbae42b -r 95c24699272e third
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/third Wed Jan 01 10:01:00 2020 +0000
@@ -0,0 +1,1 @@
+third
templater: evaluate arguments passed to diff() appropriately Before this patch, diff() crashed by passing non-string expression because it didn't evaluate arguments at all.
2015-06-13 14:14:22 +03:00
$ hg log -r 8 -T "{diff('FOURTH'|lower)}"
diff -r 29114dbae42b -r 95c24699272e fourth
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/fourth Wed Jan 01 10:01:00 2020 +0000
@@ -0,0 +1,1 @@
+second
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
$ cd ..
latesttag:
$ hg init latesttag
$ cd latesttag
$ echo a > file
$ hg ci -Am a -d '0 0'
adding file
$ echo b >> file
$ hg ci -m b -d '1 0'
$ echo c >> head1
$ hg ci -Am h1c -d '2 0'
adding head1
$ hg update -q 1
$ echo d >> head2
$ hg ci -Am h2d -d '3 0'
adding head2
created new head
$ echo e >> head2
$ hg ci -m h2e -d '4 0'
$ hg merge -q
date: allow %z in format (issue4040)
2013-11-08 01:24:23 +04:00
$ hg ci -m merge -d '5 -3600'
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
No tag set:
$ hg log --template '{rev}: {latesttag}+{latesttagdistance}\n'
5: null+5
4: null+4
3: null+3
2: null+3
1: null+2
0: null+1
spelling: fixes from spell checker
2014-04-13 21:01:00 +04:00
One common tag: longest path wins:
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
$ hg tag -r 1 -m t1 -d '6 0' t1
$ hg log --template '{rev}: {latesttag}+{latesttagdistance}\n'
6: t1+4
5: t1+3
4: t1+2
3: t1+1
2: t1+1
1: t1+0
0: null+1
One ancestor tag: more recent wins:
$ hg tag -r 2 -m t2 -d '7 0' t2
$ hg log --template '{rev}: {latesttag}+{latesttagdistance}\n'
7: t2+3
6: t2+2
5: t2+1
4: t1+2
3: t1+1
2: t2+0
1: t1+0
0: null+1
Two branch tags: more recent wins:
$ hg tag -r 3 -m t3 -d '8 0' t3
$ hg log --template '{rev}: {latesttag}+{latesttagdistance}\n'
8: t3+5
7: t3+4
6: t3+3
5: t3+2
4: t3+1
3: t3+0
2: t2+0
1: t1+0
0: null+1
Merged tag overrides:
$ hg tag -r 5 -m t5 -d '9 0' t5
$ hg tag -r 3 -m at3 -d '10 0' at3
$ hg log --template '{rev}: {latesttag}+{latesttagdistance}\n'
10: t5+5
9: t5+4
8: t5+3
7: t5+2
6: t5+1
5: t5+0
4: at3:t3+1
3: at3:t3+0
2: t2+0
1: t1+0
0: null+1
templatekw: add {changes}, {distance} and {tag} to the {latesttag} keyword
2015-08-25 06:30:17 +03:00
$ hg log --template "{rev}: {latesttag % '{tag}+{distance},{changes} '}\n"
10: t5+5,5
9: t5+4,4
8: t5+3,3
7: t5+2,2
6: t5+1,1
5: t5+0,0
4: at3+1,1 t3+1,1
3: at3+0,0 t3+0,0
2: t2+0,0
1: t1+0,0
0: null+1,1
templater: introduce {latesttag()} function to match a pattern (issue4184) This allows the latest class of tag to be found, such as a release candidate or final build, instead of just the absolute latest. It doesn't appear that the existing keyword can be given an optional argument. There is a keyword, function and filter for 'date', so it doesn't seem harmful to introduce a new function with the same name as an existing keyword. Most functions are pretty Mercurial agnostic, but there is {revset()} as precedent. Even though templatekw.getlatesttags() returns a single tuple, one entry of which is a list, it is simplest to present this as a list of tags instead of a single item, with each tag having a distance and change count attribute. It is also closer to how {latesttag} returns a list of tags, and how this function works when not given a '%' operator.
2015-08-24 06:44:58 +03:00
$ hg log --template "{rev}: {latesttag('re:^t[13]$') % '{tag}, C: {changes}, D: {distance}'}\n"
10: t3, C: 8, D: 7
9: t3, C: 7, D: 6
8: t3, C: 6, D: 5
7: t3, C: 5, D: 4
6: t3, C: 4, D: 3
5: t3, C: 3, D: 2
4: t3, C: 1, D: 1
3: t3, C: 0, D: 0
2: t1, C: 1, D: 1
1: t1, C: 0, D: 0
0: null, C: 1, D: 1
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
$ cd ..
tests: added a short description to issue numbers Many tests already had a short line to describe what IssueXXX is about. I find that quite useful when reading a test.
2010-09-24 12:13:49 +04:00
Style path expansion: issue1948 - ui.style option doesn't work on OSX
if it is a relative path
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
$ mkdir -p home/styles
$ cat > home/styles/teststyle <<EOF
> changeset = 'test {rev}:{node|short}\n'
> EOF
$ HOME=`pwd`/home; export HOME
$ cat > latesttag/.hg/hgrc <<EOF
> [ui]
> style = ~/styles/teststyle
> EOF
$ hg -R latesttag tip
date: allow %z in format (issue4040)
2013-11-08 01:24:23 +04:00
test 10:9b4a630e5f5f
tests: unify test-command-template
2010-09-14 21:31:00 +04:00
Test recursive showlist template (issue1989):
$ cat > style1989 <<EOF
> changeset = '{file_mods}{manifest}{extras}'
> file_mod = 'M|{author|person}\n'
> manifest = '{rev},{author}\n'
> extra = '{key}: {author}\n'
> EOF
$ hg -R latesttag log -r tip --style=style1989
M|test
10,test
branch: test
templating: make new-style templating features work with command line lists
2012-09-22 03:54:00 +04:00
Test new-style inline templating:
$ hg log -R latesttag -r tip --template 'modified files: {file_mods % " {file}\n"}\n'
modified files: .hgtags
templater: handle exception when applying map operator to non-iterable object Before this, "{noniterable % template}" raised an exception. This tries to provide a better indication for the common case, where a left-hand-side expression is a keyword.
2016-02-14 07:58:46 +03:00
$ hg log -R latesttag -r tip -T '{rev % "a"}\n'
hg: parse error: keyword 'rev' is not iterable
[255]
$ hg log -R latesttag -r tip -T '{get(extras, "unknown") % "a"}\n'
hg: parse error: None is not iterable
[255]
template: call runtemplate on the src argument to sub This allows using a template keyword on calls to the sub function and brings the function inline with most other semantics of the other template functions.
2013-04-11 04:27:49 +04:00
Test the sub function of templating for expansion:
$ hg log -R latesttag -r 10 --template '{sub("[0-9]", "x", "{rev}")}\n'
xx
templater: add strip function with chars as an extra argument This allows specifying characters to strip, like the Python strip function.
2013-06-25 21:02:22 +04:00
templater: catch regexp error at sub() function This patch splits re.sub() into re.compile() and sub() so that it can distinguish which argument causes re.error.
2015-09-07 15:58:17 +03:00
$ hg log -R latesttag -r 10 -T '{sub("[", "x", rev)}\n'
hg: parse error: sub got an invalid pattern: [
[255]
$ hg log -R latesttag -r 10 -T '{sub("[0-9]", r"\1", rev)}\n'
hg: parse error: sub got an invalid replacement: \1
[255]
templater: add strip function with chars as an extra argument This allows specifying characters to strip, like the Python strip function.
2013-06-25 21:02:22 +04:00
Test the strip function with chars specified:
$ hg log -R latesttag --template '{desc}\n'
at3
t5
t3
t2
t1
merge
h2e
h2d
h1c
b
a
$ hg log -R latesttag --template '{strip(desc, "te")}\n'
at3
5
3
2
1
merg
h2
h2d
h1c
b
a
date: allow %z in format (issue4040)
2013-11-08 01:24:23 +04:00
Test date format:
$ hg log -R latesttag --template 'date: {date(date, "%y %m %d %S %z")}\n'
date: 70 01 01 10 +0000
date: 70 01 01 09 +0000
date: 70 01 01 08 +0000
date: 70 01 01 07 +0000
date: 70 01 01 06 +0000
date: 70 01 01 05 +0100
date: 70 01 01 04 +0000
date: 70 01 01 03 +0000
date: 70 01 01 02 +0000
date: 70 01 01 01 +0000
date: 70 01 01 00 +0000
templater: fix escaping in nested string literals (issue4102) Before the templater got extended for nested expressions, it made sense to decode string escapes across the whole string. Now we do it on a piece by piece basis.
2013-11-18 23:02:26 +04:00
templater: fix crash by passing invalid object to date() function "date information" is somewhat obscure, but we call it that way in templatekw.showdate().
2015-05-03 11:33:14 +03:00
Test invalid date:
$ hg log -R latesttag -T '{date(rev)}\n'
hg: parse error: date expects a date information
[255]
templater: tokenize decimal integer literal (issue4638) (BC) Before this patch, we had to quote integer literals to pass to template functions. It was error-prone, so we should allow "word(0, x)" syntax. Currently only decimal integers are allowed. It's easy to support 0x, 0b and 0 prefixes, but I don't think they are useful. This patch assumes that template keywords and names defined in map files do not start with digits, except for positional variables seen in the schemes extension.
2015-05-01 14:43:55 +03:00
Test integer literal:
templater: add debugtemplate command This is useful for debugging template parsing. Several tests are ported to this command.
2016-02-13 19:06:12 +03:00
$ hg debugtemplate -v '{(0)}\n'
(template
(group
('integer', '0'))
('string', '\n'))
templater: tokenize decimal integer literal (issue4638) (BC) Before this patch, we had to quote integer literals to pass to template functions. It was error-prone, so we should allow "word(0, x)" syntax. Currently only decimal integers are allowed. It's easy to support 0x, 0b and 0 prefixes, but I don't think they are useful. This patch assumes that template keywords and names defined in map files do not start with digits, except for positional variables seen in the schemes extension.
2015-05-01 14:43:55 +03:00
0
templater: add debugtemplate command This is useful for debugging template parsing. Several tests are ported to this command.
2016-02-13 19:06:12 +03:00
$ hg debugtemplate -v '{(123)}\n'
(template
(group
('integer', '123'))
('string', '\n'))
templater: tokenize decimal integer literal (issue4638) (BC) Before this patch, we had to quote integer literals to pass to template functions. It was error-prone, so we should allow "word(0, x)" syntax. Currently only decimal integers are allowed. It's easy to support 0x, 0b and 0 prefixes, but I don't think they are useful. This patch assumes that template keywords and names defined in map files do not start with digits, except for positional variables seen in the schemes extension.
2015-05-01 14:43:55 +03:00
123
templater: add debugtemplate command This is useful for debugging template parsing. Several tests are ported to this command.
2016-02-13 19:06:12 +03:00
$ hg debugtemplate -v '{(-4)}\n'
(template
(group
('integer', '-4'))
('string', '\n'))
templater: tokenize decimal integer literal (issue4638) (BC) Before this patch, we had to quote integer literals to pass to template functions. It was error-prone, so we should allow "word(0, x)" syntax. Currently only decimal integers are allowed. It's easy to support 0x, 0b and 0 prefixes, but I don't think they are useful. This patch assumes that template keywords and names defined in map files do not start with digits, except for positional variables seen in the schemes extension.
2015-05-01 14:43:55 +03:00
-4
templater: add debugtemplate command This is useful for debugging template parsing. Several tests are ported to this command.
2016-02-13 19:06:12 +03:00
$ hg debugtemplate '{(-)}\n'
templater: tokenize decimal integer literal (issue4638) (BC) Before this patch, we had to quote integer literals to pass to template functions. It was error-prone, so we should allow "word(0, x)" syntax. Currently only decimal integers are allowed. It's easy to support 0x, 0b and 0 prefixes, but I don't think they are useful. This patch assumes that template keywords and names defined in map files do not start with digits, except for positional variables seen in the schemes extension.
2015-05-01 14:43:55 +03:00
hg: parse error at 2: integer literal without digits
[255]
templater: add debugtemplate command This is useful for debugging template parsing. Several tests are ported to this command.
2016-02-13 19:06:12 +03:00
$ hg debugtemplate '{(-a)}\n'
templater: tokenize decimal integer literal (issue4638) (BC) Before this patch, we had to quote integer literals to pass to template functions. It was error-prone, so we should allow "word(0, x)" syntax. Currently only decimal integers are allowed. It's easy to support 0x, 0b and 0 prefixes, but I don't think they are useful. This patch assumes that template keywords and names defined in map files do not start with digits, except for positional variables seen in the schemes extension.
2015-05-01 14:43:55 +03:00
hg: parse error at 2: integer literal without digits
[255]
top-level integer literal is interpreted as symbol (i.e. variable name):
templater: add debugtemplate command This is useful for debugging template parsing. Several tests are ported to this command.
2016-02-13 19:06:12 +03:00
$ hg debugtemplate -D 1=one -v '{1}\n'
(template
('integer', '1')
('string', '\n'))
one
$ hg debugtemplate -D 1=one -v '{if("t", "{1}")}\n'
(template
(func
('symbol', 'if')
(list
('string', 't')
(template
('integer', '1'))))
('string', '\n'))
one
$ hg debugtemplate -D 1=one -v '{1|stringify}\n'
(template
(|
('integer', '1')
('symbol', 'stringify'))
('string', '\n'))
one
templater: tokenize decimal integer literal (issue4638) (BC) Before this patch, we had to quote integer literals to pass to template functions. It was error-prone, so we should allow "word(0, x)" syntax. Currently only decimal integers are allowed. It's easy to support 0x, 0b and 0 prefixes, but I don't think they are useful. This patch assumes that template keywords and names defined in map files do not start with digits, except for positional variables seen in the schemes extension.
2015-05-01 14:43:55 +03:00
unless explicit symbol is expected:
$ hg log -Ra -r0 -T '{desc|1}\n'
hg: parse error: expected a symbol, got 'integer'
[255]
$ hg log -Ra -r0 -T '{1()}\n'
hg: parse error: expected a symbol, got 'integer'
[255]
templater: take any string literals as template, but not for rawstring (BC) This patch series is intended to unify the interpretation of string literals. It is breaking change that boldly assumes a. string literal "..." never contains template-like fragment or it is intended to be a template b. we tend to use raw string literal r"..." for regexp pattern in which "{" should have different meaning Currently, we don't have a comprehensible rule how string literals are evaluated in template functions. For example, fill() takes "initialindent" and "hangindent" as templates, but not for "text", whereas "text" is a template in pad() function. date(date, fmt) diff(includepattern, excludepattern) fill(text, width, initialident: T, hangindent: T) get(dict, key) if(expr, then: T, else: T) ifcontains(search, thing, then: T, else: T) ifeq(expr1, expr2, then: T, else: T) indent(text, indentchars, firstline) join(list, sep) label(label: T, expr: T) pad(text: T, width, fillchar, right) revset(query, formatargs...]) rstdoc(text, style) shortest(node, minlength) startswith(pattern, text) strip(text, chars) sub(pattern, replacement, expression: T) word(number, text, separator) expr % template: T T: interpret "string" or r"rawstring" as template This patch series adjusts the rule as follows: a. string literal, '' or "", starts template processing (BC) b. raw string literal, r'' or r"", disables both \-escape and template processing (BC, done by subsequent patches) c. fragment not surrounded by {} is non-templated string "ccc{'aaa'}{r'bbb'}" ------------------ *: template --- c: string --- a: template --- b: rawstring Because this can eliminate the compilation of template arguments from the evaluation phase, "hg log -Tdefault" gets faster. % cd mozilla-central % LANG=C HGRCPATH=/dev/null hg log -Tdefault -r0:10000 --time > /dev/null before: real 4.870 secs (user 4.860+0.000 sys 0.010+0.000) after: real 3.480 secs (user 3.440+0.000 sys 0.030+0.000) Also, this will allow us to parse nested templates at once for better error indication.
2015-06-13 13:49:54 +03:00
Test string literal:
templater: add debugtemplate command This is useful for debugging template parsing. Several tests are ported to this command.
2016-02-13 19:06:12 +03:00
$ hg debugtemplate -Ra -r0 -v '{"string with no template fragment"}\n'
(template
('string', 'string with no template fragment')
('string', '\n'))
templater: take any string literals as template, but not for rawstring (BC) This patch series is intended to unify the interpretation of string literals. It is breaking change that boldly assumes a. string literal "..." never contains template-like fragment or it is intended to be a template b. we tend to use raw string literal r"..." for regexp pattern in which "{" should have different meaning Currently, we don't have a comprehensible rule how string literals are evaluated in template functions. For example, fill() takes "initialindent" and "hangindent" as templates, but not for "text", whereas "text" is a template in pad() function. date(date, fmt) diff(includepattern, excludepattern) fill(text, width, initialident: T, hangindent: T) get(dict, key) if(expr, then: T, else: T) ifcontains(search, thing, then: T, else: T) ifeq(expr1, expr2, then: T, else: T) indent(text, indentchars, firstline) join(list, sep) label(label: T, expr: T) pad(text: T, width, fillchar, right) revset(query, formatargs...]) rstdoc(text, style) shortest(node, minlength) startswith(pattern, text) strip(text, chars) sub(pattern, replacement, expression: T) word(number, text, separator) expr % template: T T: interpret "string" or r"rawstring" as template This patch series adjusts the rule as follows: a. string literal, '' or "", starts template processing (BC) b. raw string literal, r'' or r"", disables both \-escape and template processing (BC, done by subsequent patches) c. fragment not surrounded by {} is non-templated string "ccc{'aaa'}{r'bbb'}" ------------------ *: template --- c: string --- a: template --- b: rawstring Because this can eliminate the compilation of template arguments from the evaluation phase, "hg log -Tdefault" gets faster. % cd mozilla-central % LANG=C HGRCPATH=/dev/null hg log -Tdefault -r0:10000 --time > /dev/null before: real 4.870 secs (user 4.860+0.000 sys 0.010+0.000) after: real 3.480 secs (user 3.440+0.000 sys 0.030+0.000) Also, this will allow us to parse nested templates at once for better error indication.
2015-06-13 13:49:54 +03:00
string with no template fragment
templater: add debugtemplate command This is useful for debugging template parsing. Several tests are ported to this command.
2016-02-13 19:06:12 +03:00
$ hg debugtemplate -Ra -r0 -v '{"template: {rev}"}\n'
(template
(template
('string', 'template: ')
('symbol', 'rev'))
('string', '\n'))
templater: take any string literals as template, but not for rawstring (BC) This patch series is intended to unify the interpretation of string literals. It is breaking change that boldly assumes a. string literal "..." never contains template-like fragment or it is intended to be a template b. we tend to use raw string literal r"..." for regexp pattern in which "{" should have different meaning Currently, we don't have a comprehensible rule how string literals are evaluated in template functions. For example, fill() takes "initialindent" and "hangindent" as templates, but not for "text", whereas "text" is a template in pad() function. date(date, fmt) diff(includepattern, excludepattern) fill(text, width, initialident: T, hangindent: T) get(dict, key) if(expr, then: T, else: T) ifcontains(search, thing, then: T, else: T) ifeq(expr1, expr2, then: T, else: T) indent(text, indentchars, firstline) join(list, sep) label(label: T, expr: T) pad(text: T, width, fillchar, right) revset(query, formatargs...]) rstdoc(text, style) shortest(node, minlength) startswith(pattern, text) strip(text, chars) sub(pattern, replacement, expression: T) word(number, text, separator) expr % template: T T: interpret "string" or r"rawstring" as template This patch series adjusts the rule as follows: a. string literal, '' or "", starts template processing (BC) b. raw string literal, r'' or r"", disables both \-escape and template processing (BC, done by subsequent patches) c. fragment not surrounded by {} is non-templated string "ccc{'aaa'}{r'bbb'}" ------------------ *: template --- c: string --- a: template --- b: rawstring Because this can eliminate the compilation of template arguments from the evaluation phase, "hg log -Tdefault" gets faster. % cd mozilla-central % LANG=C HGRCPATH=/dev/null hg log -Tdefault -r0:10000 --time > /dev/null before: real 4.870 secs (user 4.860+0.000 sys 0.010+0.000) after: real 3.480 secs (user 3.440+0.000 sys 0.030+0.000) Also, this will allow us to parse nested templates at once for better error indication.
2015-06-13 13:49:54 +03:00
template: 0
templater: add debugtemplate command This is useful for debugging template parsing. Several tests are ported to this command.
2016-02-13 19:06:12 +03:00
$ hg debugtemplate -Ra -r0 -v '{r"rawstring: {rev}"}\n'
(template
('string', 'rawstring: {rev}')
('string', '\n'))
templater: take any string literals as template, but not for rawstring (BC) This patch series is intended to unify the interpretation of string literals. It is breaking change that boldly assumes a. string literal "..." never contains template-like fragment or it is intended to be a template b. we tend to use raw string literal r"..." for regexp pattern in which "{" should have different meaning Currently, we don't have a comprehensible rule how string literals are evaluated in template functions. For example, fill() takes "initialindent" and "hangindent" as templates, but not for "text", whereas "text" is a template in pad() function. date(date, fmt) diff(includepattern, excludepattern) fill(text, width, initialident: T, hangindent: T) get(dict, key) if(expr, then: T, else: T) ifcontains(search, thing, then: T, else: T) ifeq(expr1, expr2, then: T, else: T) indent(text, indentchars, firstline) join(list, sep) label(label: T, expr: T) pad(text: T, width, fillchar, right) revset(query, formatargs...]) rstdoc(text, style) shortest(node, minlength) startswith(pattern, text) strip(text, chars) sub(pattern, replacement, expression: T) word(number, text, separator) expr % template: T T: interpret "string" or r"rawstring" as template This patch series adjusts the rule as follows: a. string literal, '' or "", starts template processing (BC) b. raw string literal, r'' or r"", disables both \-escape and template processing (BC, done by subsequent patches) c. fragment not surrounded by {} is non-templated string "ccc{'aaa'}{r'bbb'}" ------------------ *: template --- c: string --- a: template --- b: rawstring Because this can eliminate the compilation of template arguments from the evaluation phase, "hg log -Tdefault" gets faster. % cd mozilla-central % LANG=C HGRCPATH=/dev/null hg log -Tdefault -r0:10000 --time > /dev/null before: real 4.870 secs (user 4.860+0.000 sys 0.010+0.000) after: real 3.480 secs (user 3.440+0.000 sys 0.030+0.000) Also, this will allow us to parse nested templates at once for better error indication.
2015-06-13 13:49:54 +03:00
rawstring: {rev}
templater: add debugtemplate command This is useful for debugging template parsing. Several tests are ported to this command.
2016-02-13 19:06:12 +03:00
$ hg debugtemplate -Ra -r0 -v '{files % r"rawstring: {file}"}\n'
(template
(%
('symbol', 'files')
('string', 'rawstring: {file}'))
('string', '\n'))
templater: relax type of mapped template Now compiled template fragments are packed into a generic type, (func, data), a string can be a valid template. This change allows us to unwrap a trivial string node. See the next patch for details.
2016-02-14 09:42:49 +03:00
rawstring: {file}
templater: do not reevaluate rawstring as template (BC) The previous patch made 'string' is always interpreted as a template. So this patch removes the special handling of r'rawstring' instead. Now r'' disables template processing at all.
2015-06-10 15:44:43 +03:00
merge with stable
2013-11-19 20:29:56 +04:00
Test string escaping:
test-command-template.t: fix failure due to trailing whitespace
2013-11-22 00:47:03 +04:00
templater: fix escaping in nested string literals (issue4102) Before the templater got extended for nested expressions, it made sense to decode string escapes across the whole string. Now we do it on a piece by piece basis.
2013-11-18 23:02:26 +04:00
$ hg log -R latesttag -r 0 --template '>\n<>\\n<{if(rev, "[>\n<>\\n<]")}>\n<>\\n<\n'
>
<>\n<[>
<>\n<]>
<>\n<
templater: only recursively evaluate string literals as templates (issue4103)
2013-11-19 00:37:09 +04:00
templater: do not process \-escapes at parsestring() (issue4290) This patch brings back pre-2.8.1 behavior. The result of parsestring() is stored in templater's cache, t.cache, and then it is parsed as a template string by compiletemplate(). So t.cache should keep an unparsed string no matter if it is sourced from config value. Otherwise backslashes would be processed twice. The test vector is borrowed from 83ff877959a6.
2015-05-04 03:54:01 +03:00
$ hg log -R latesttag -r 0 \
> --config ui.logtemplate='>\n<>\\n<{if(rev, "[>\n<>\\n<]")}>\n<>\\n<\n'
>
<>\n<[>
<>\n<]>
<>\n<
$ hg log -R latesttag -r 0 -T esc \
> --config templates.esc='>\n<>\\n<{if(rev, "[>\n<>\\n<]")}>\n<>\\n<\n'
>
<>\n<[>
<>\n<]>
<>\n<
$ cat <<'EOF' > esctmpl
> changeset = '>\n<>\\n<{if(rev, "[>\n<>\\n<]")}>\n<>\\n<\n'
> EOF
$ hg log -R latesttag -r 0 --style ./esctmpl
>
<>\n<[>
<>\n<]>
<>\n<
templater: fix handling of \-escapes in raw string literals The backslash character should start escape sequences no matter if a string is prefixed with 'r'. They are just not interpreted as escape sequences in raw strings. revset.tokenize() handles them correctly, but templater didn't. https://docs.python.org/2/reference/lexical_analysis.html#string-literals
2015-06-21 07:24:43 +03:00
Test string escaping of quotes:
$ hg log -Ra -r0 -T '{"\""}\n'
"
$ hg log -Ra -r0 -T '{"\\\""}\n'
\"
$ hg log -Ra -r0 -T '{r"\""}\n'
\"
$ hg log -Ra -r0 -T '{r"\\\""}\n'
\\\"
templater: parse \"...\" as string for 2.9.2-3.4 compatibility (issue4733) As of Mercurial 3.4, there were several syntax rules to process nested template strings. Unfortunately, they were inconsistent and conflicted each other. a. buildmap() rule - template string is _parsed_ as string, and parsed as template - <\"> is not allowed in nested template: {xs % "{f(\"{x}\")}"} -> parse error - template escaping <\{> is handled consistently: {xs % "\{x}"} -> escaped b. _evalifliteral() rule - template string is _interpreted_ as string, and parsed as template in crafted environment to avoid double processing of escape sequences - <\"> is allowed in nested template: {if(x, "{f(\"{x}\")}")} - <\{> and escape sequences in string literal in nested template are not handled well c. pad() rule - template string is first interpreted as string, and parsed as template, which means escape sequences are processed twice - <\"> is allowed in nested template: {pad("{xs % \"{x}\"}', 10)} Because of the issue of template escaping, issue4714, 56e0b66a4c27 (in stable) unified the rule (b) to (a). Then, 41e044cfb1ef (in default) unified the rule (c) to (b) = (a). But they disabled the following syntax that was somewhat considered valid. {if(rev, "{if(rev, \"{rev}\")}")} {pad("{files % \"{file}\"}", 10)} So, this patch introduces \"...\" literal to work around the escaped-quoted nested template strings. Because this parsing rule exists only for the backward compatibility, it is designed to copy the behavior of old _evalifliteral() as possible. Future patches will introduce a better parsing rule similar to a command substitution of POSIX shells or a string interpolation of Ruby, where extra escapes won't be necessary at all. {pad("{files % "{file}"}", 10)} ~~~~~~~~~~~~~~~~~~ parsed as a template, not as a string Because <\> character wasn't allowed in a template fragment, this patch won't introduce more breakages. But the syntax of nested templates are interpreted differently by people, there might be unknown issues. So if we want, we could instead remove e926f2ef639a, 72be08a15d8d and 56e0b66a4c27 from the stable branch as the bug fixed by these patches existed for longer periods. 554d6fcc3c8, "strip single backslash before quotation mark in quoted template", should be superseded by this patch. I'll remove it later.
2015-06-25 16:07:38 +03:00
merge with stable
2015-07-02 00:33:31 +03:00
$ hg log -Ra -r0 -T '{"\""}\n'
"
$ hg log -Ra -r0 -T '{"\\\""}\n'
\"
$ hg log -Ra -r0 -T '{r"\""}\n'
\"
$ hg log -Ra -r0 -T '{r"\\\""}\n'
\\\"
templater: strip single backslash before quotation mark in quoted template e926f2ef639a fixed the issue of double escapes, but it made the following template fail with syntax error because of <\">. Strictly speaking, <\"> appears to be invalid in non-string part, but we are likely to escape <"> if surrounded by quotes, and we are used to write such templates by trial and error. [templates] sl = "{tags % \"{ifeq(tag,'tip','',label('log.tag', ' {tag}'))}\"}" So, for backward compatibility between 2.8.1 and 3.4, a single backslash before quotation mark is stripped only in quoted template. We don't care for <\"> in string literal in quoted template, which never worked as expected before. template result --------- ------------------------ {\"\"} parse error "{""}" {""} -> <> "{\"\"}" {""} -> <> {"\""} {"\""} -> <"> '{"\""}' {"\""} -> <"> "{"\""}" parse error (don't care)
2015-05-08 12:11:26 +03:00
Test exception in quoted template. single backslash before quotation mark is
stripped before parsing:
$ cat <<'EOF' > escquotetmpl
> changeset = "\" \\" \\\" \\\\" {files % \"{file}\"}\n"
> EOF
$ cd latesttag
$ hg log -r 2 --style ../escquotetmpl
" \" \" \\" head1
$ hg log -r 2 -T esc --config templates.esc='"{\"valid\"}\n"'
valid
$ hg log -r 2 -T esc --config templates.esc="'"'{\'"'"'valid\'"'"'}\n'"'"
valid
merge with stable
2015-07-02 00:33:31 +03:00
Test compatibility with 2.9.2-3.4 of escaped quoted strings in nested
_evalifliteral() templates (issue4733):
templater: parse \"...\" as string for 2.9.2-3.4 compatibility (issue4733) As of Mercurial 3.4, there were several syntax rules to process nested template strings. Unfortunately, they were inconsistent and conflicted each other. a. buildmap() rule - template string is _parsed_ as string, and parsed as template - <\"> is not allowed in nested template: {xs % "{f(\"{x}\")}"} -> parse error - template escaping <\{> is handled consistently: {xs % "\{x}"} -> escaped b. _evalifliteral() rule - template string is _interpreted_ as string, and parsed as template in crafted environment to avoid double processing of escape sequences - <\"> is allowed in nested template: {if(x, "{f(\"{x}\")}")} - <\{> and escape sequences in string literal in nested template are not handled well c. pad() rule - template string is first interpreted as string, and parsed as template, which means escape sequences are processed twice - <\"> is allowed in nested template: {pad("{xs % \"{x}\"}', 10)} Because of the issue of template escaping, issue4714, 56e0b66a4c27 (in stable) unified the rule (b) to (a). Then, 41e044cfb1ef (in default) unified the rule (c) to (b) = (a). But they disabled the following syntax that was somewhat considered valid. {if(rev, "{if(rev, \"{rev}\")}")} {pad("{files % \"{file}\"}", 10)} So, this patch introduces \"...\" literal to work around the escaped-quoted nested template strings. Because this parsing rule exists only for the backward compatibility, it is designed to copy the behavior of old _evalifliteral() as possible. Future patches will introduce a better parsing rule similar to a command substitution of POSIX shells or a string interpolation of Ruby, where extra escapes won't be necessary at all. {pad("{files % "{file}"}", 10)} ~~~~~~~~~~~~~~~~~~ parsed as a template, not as a string Because <\> character wasn't allowed in a template fragment, this patch won't introduce more breakages. But the syntax of nested templates are interpreted differently by people, there might be unknown issues. So if we want, we could instead remove e926f2ef639a, 72be08a15d8d and 56e0b66a4c27 from the stable branch as the bug fixed by these patches existed for longer periods. 554d6fcc3c8, "strip single backslash before quotation mark in quoted template", should be superseded by this patch. I'll remove it later.
2015-06-25 16:07:38 +03:00
$ hg log -r 2 -T '{if(rev, "\"{rev}")}\n'
"2
$ hg log -r 2 -T '{if(rev, "{if(rev, \"\\\"{rev}\")}")}\n'
"2
$ hg log -r 2 -T '{if(rev, "{if(rev, \"{if(rev, \\\"\\\\\\\"{rev}\\\")}\")}")}\n'
"2
$ hg log -r 2 -T '{if(rev, "\\\"")}\n'
\"
$ hg log -r 2 -T '{if(rev, "{if(rev, \"\\\\\\\"\")}")}\n'
\"
$ hg log -r 2 -T '{if(rev, "{if(rev, \"{if(rev, \\\"\\\\\\\\\\\\\\\"\\\")}\")}")}\n'
\"
$ hg log -r 2 -T '{if(rev, r"\\\"")}\n'
\\\"
$ hg log -r 2 -T '{if(rev, "{if(rev, r\"\\\\\\\"\")}")}\n'
\\\"
$ hg log -r 2 -T '{if(rev, "{if(rev, \"{if(rev, r\\\"\\\\\\\\\\\\\\\"\\\")}\")}")}\n'
\\\"
escaped single quotes and errors:
$ hg log -r 2 -T "{if(rev, '{if(rev, \'foo\')}')}"'\n'
foo
$ hg log -r 2 -T "{if(rev, '{if(rev, r\'foo\')}')}"'\n'
foo
$ hg log -r 2 -T '{if(rev, "{if(rev, \")}")}\n'
templater: introduce one-pass parsing of nested template strings Instead of re-parsing quoted strings as templates, the tokenizer can delegate the parsing of nested template strings to the parser. It has two benefits: 1. syntax errors can be reported with absolute positions 2. nested template can use quotes just like shell: "{"{rev}"}" It doesn't sound nice that the tokenizer recurses into the parser. We could instead make the tokenize itself recursive, but it would be much more complicated because we would have to adjust binding strengths carefully and put dummy infix operators to concatenate template fragments. Now "string" token without r"" never appears. It will be removed by the next patch.
2015-06-15 17:11:35 +03:00
hg: parse error at 21: unterminated string
templater: parse \"...\" as string for 2.9.2-3.4 compatibility (issue4733) As of Mercurial 3.4, there were several syntax rules to process nested template strings. Unfortunately, they were inconsistent and conflicted each other. a. buildmap() rule - template string is _parsed_ as string, and parsed as template - <\"> is not allowed in nested template: {xs % "{f(\"{x}\")}"} -> parse error - template escaping <\{> is handled consistently: {xs % "\{x}"} -> escaped b. _evalifliteral() rule - template string is _interpreted_ as string, and parsed as template in crafted environment to avoid double processing of escape sequences - <\"> is allowed in nested template: {if(x, "{f(\"{x}\")}")} - <\{> and escape sequences in string literal in nested template are not handled well c. pad() rule - template string is first interpreted as string, and parsed as template, which means escape sequences are processed twice - <\"> is allowed in nested template: {pad("{xs % \"{x}\"}', 10)} Because of the issue of template escaping, issue4714, 56e0b66a4c27 (in stable) unified the rule (b) to (a). Then, 41e044cfb1ef (in default) unified the rule (c) to (b) = (a). But they disabled the following syntax that was somewhat considered valid. {if(rev, "{if(rev, \"{rev}\")}")} {pad("{files % \"{file}\"}", 10)} So, this patch introduces \"...\" literal to work around the escaped-quoted nested template strings. Because this parsing rule exists only for the backward compatibility, it is designed to copy the behavior of old _evalifliteral() as possible. Future patches will introduce a better parsing rule similar to a command substitution of POSIX shells or a string interpolation of Ruby, where extra escapes won't be necessary at all. {pad("{files % "{file}"}", 10)} ~~~~~~~~~~~~~~~~~~ parsed as a template, not as a string Because <\> character wasn't allowed in a template fragment, this patch won't introduce more breakages. But the syntax of nested templates are interpreted differently by people, there might be unknown issues. So if we want, we could instead remove e926f2ef639a, 72be08a15d8d and 56e0b66a4c27 from the stable branch as the bug fixed by these patches existed for longer periods. 554d6fcc3c8, "strip single backslash before quotation mark in quoted template", should be superseded by this patch. I'll remove it later.
2015-06-25 16:07:38 +03:00
[255]
$ hg log -r 2 -T '{if(rev, \"\\"")}\n'
templater: create string unescape helper (issue4798) This gives us a unified place to do error-handling of string-escaping syntax errors
2015-09-10 00:43:45 +03:00
hg: parse error: trailing \ in string
templater: parse \"...\" as string for 2.9.2-3.4 compatibility (issue4733) As of Mercurial 3.4, there were several syntax rules to process nested template strings. Unfortunately, they were inconsistent and conflicted each other. a. buildmap() rule - template string is _parsed_ as string, and parsed as template - <\"> is not allowed in nested template: {xs % "{f(\"{x}\")}"} -> parse error - template escaping <\{> is handled consistently: {xs % "\{x}"} -> escaped b. _evalifliteral() rule - template string is _interpreted_ as string, and parsed as template in crafted environment to avoid double processing of escape sequences - <\"> is allowed in nested template: {if(x, "{f(\"{x}\")}")} - <\{> and escape sequences in string literal in nested template are not handled well c. pad() rule - template string is first interpreted as string, and parsed as template, which means escape sequences are processed twice - <\"> is allowed in nested template: {pad("{xs % \"{x}\"}', 10)} Because of the issue of template escaping, issue4714, 56e0b66a4c27 (in stable) unified the rule (b) to (a). Then, 41e044cfb1ef (in default) unified the rule (c) to (b) = (a). But they disabled the following syntax that was somewhat considered valid. {if(rev, "{if(rev, \"{rev}\")}")} {pad("{files % \"{file}\"}", 10)} So, this patch introduces \"...\" literal to work around the escaped-quoted nested template strings. Because this parsing rule exists only for the backward compatibility, it is designed to copy the behavior of old _evalifliteral() as possible. Future patches will introduce a better parsing rule similar to a command substitution of POSIX shells or a string interpolation of Ruby, where extra escapes won't be necessary at all. {pad("{files % "{file}"}", 10)} ~~~~~~~~~~~~~~~~~~ parsed as a template, not as a string Because <\> character wasn't allowed in a template fragment, this patch won't introduce more breakages. But the syntax of nested templates are interpreted differently by people, there might be unknown issues. So if we want, we could instead remove e926f2ef639a, 72be08a15d8d and 56e0b66a4c27 from the stable branch as the bug fixed by these patches existed for longer periods. 554d6fcc3c8, "strip single backslash before quotation mark in quoted template", should be superseded by this patch. I'll remove it later.
2015-06-25 16:07:38 +03:00
[255]
$ hg log -r 2 -T '{if(rev, r\"\\"")}\n'
templater: create string unescape helper (issue4798) This gives us a unified place to do error-handling of string-escaping syntax errors
2015-09-10 00:43:45 +03:00
hg: parse error: trailing \ in string
templater: parse \"...\" as string for 2.9.2-3.4 compatibility (issue4733) As of Mercurial 3.4, there were several syntax rules to process nested template strings. Unfortunately, they were inconsistent and conflicted each other. a. buildmap() rule - template string is _parsed_ as string, and parsed as template - <\"> is not allowed in nested template: {xs % "{f(\"{x}\")}"} -> parse error - template escaping <\{> is handled consistently: {xs % "\{x}"} -> escaped b. _evalifliteral() rule - template string is _interpreted_ as string, and parsed as template in crafted environment to avoid double processing of escape sequences - <\"> is allowed in nested template: {if(x, "{f(\"{x}\")}")} - <\{> and escape sequences in string literal in nested template are not handled well c. pad() rule - template string is first interpreted as string, and parsed as template, which means escape sequences are processed twice - <\"> is allowed in nested template: {pad("{xs % \"{x}\"}', 10)} Because of the issue of template escaping, issue4714, 56e0b66a4c27 (in stable) unified the rule (b) to (a). Then, 41e044cfb1ef (in default) unified the rule (c) to (b) = (a). But they disabled the following syntax that was somewhat considered valid. {if(rev, "{if(rev, \"{rev}\")}")} {pad("{files % \"{file}\"}", 10)} So, this patch introduces \"...\" literal to work around the escaped-quoted nested template strings. Because this parsing rule exists only for the backward compatibility, it is designed to copy the behavior of old _evalifliteral() as possible. Future patches will introduce a better parsing rule similar to a command substitution of POSIX shells or a string interpolation of Ruby, where extra escapes won't be necessary at all. {pad("{files % "{file}"}", 10)} ~~~~~~~~~~~~~~~~~~ parsed as a template, not as a string Because <\> character wasn't allowed in a template fragment, this patch won't introduce more breakages. But the syntax of nested templates are interpreted differently by people, there might be unknown issues. So if we want, we could instead remove e926f2ef639a, 72be08a15d8d and 56e0b66a4c27 from the stable branch as the bug fixed by these patches existed for longer periods. 554d6fcc3c8, "strip single backslash before quotation mark in quoted template", should be superseded by this patch. I'll remove it later.
2015-06-25 16:07:38 +03:00
[255]
templater: strip single backslash before quotation mark in quoted template e926f2ef639a fixed the issue of double escapes, but it made the following template fail with syntax error because of <\">. Strictly speaking, <\"> appears to be invalid in non-string part, but we are likely to escape <"> if surrounded by quotes, and we are used to write such templates by trial and error. [templates] sl = "{tags % \"{ifeq(tag,'tip','',label('log.tag', ' {tag}'))}\"}" So, for backward compatibility between 2.8.1 and 3.4, a single backslash before quotation mark is stripped only in quoted template. We don't care for <\"> in string literal in quoted template, which never worked as expected before. template result --------- ------------------------ {\"\"} parse error "{""}" {""} -> <> "{\"\"}" {""} -> <> {"\""} {"\""} -> <"> '{"\""}' {"\""} -> <"> "{"\""}" parse error (don't care)
2015-05-08 12:11:26 +03:00
$ cd ..
templater: strictly parse leading backslashes of '{' (issue4569) (BC) Because double backslashes are processed as a string escape sequence, '\\{' should start the template syntax. On the other hand, r'' disables any sort of \-escapes, so r'\{' can go either way, never start the template syntax or always start it. I simply chose the latter, which means r'\{' is the same as '\\{'.
2015-05-04 04:17:34 +03:00
Test leading backslashes:
$ cd latesttag
templater: do not reevaluate rawstring as template (BC) The previous patch made 'string' is always interpreted as a template. So this patch removes the special handling of r'rawstring' instead. Now r'' disables template processing at all.
2015-06-10 15:44:43 +03:00
$ hg log -r 2 -T '\{rev} {files % "\{file}"}\n'
{rev} {file}
$ hg log -r 2 -T '\\{rev} {files % "\\{file}"}\n'
\2 \head1
$ hg log -r 2 -T '\\\{rev} {files % "\\\{file}"}\n'
\{rev} \{file}
templater: strictly parse leading backslashes of '{' (issue4569) (BC) Because double backslashes are processed as a string escape sequence, '\\{' should start the template syntax. On the other hand, r'' disables any sort of \-escapes, so r'\{' can go either way, never start the template syntax or always start it. I simply chose the latter, which means r'\{' is the same as '\\{'.
2015-05-04 04:17:34 +03:00
$ cd ..
templater: do not preprocess template string in "if" expression (issue4714) The problem was spotted at cd1b50e99ed8, that says "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 workaround is no longer valid since 72be08a15d8d introduced strict parsing of '\{'. Instead, we should interpret bare token as "string" or "rawstring" template. This is what buildmap() does at parsing phase.
2015-06-08 12:14:22 +03:00
Test leading backslashes in "if" expression (issue4714):
$ cd latesttag
$ hg log -r 2 -T '{if("1", "\{rev}")} {if("1", r"\{rev}")}\n'
templater: do not reevaluate rawstring as template (BC) The previous patch made 'string' is always interpreted as a template. So this patch removes the special handling of r'rawstring' instead. Now r'' disables template processing at all.
2015-06-10 15:44:43 +03:00
{rev} \{rev}
templater: do not preprocess template string in "if" expression (issue4714) The problem was spotted at cd1b50e99ed8, that says "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 workaround is no longer valid since 72be08a15d8d introduced strict parsing of '\{'. Instead, we should interpret bare token as "string" or "rawstring" template. This is what buildmap() does at parsing phase.
2015-06-08 12:14:22 +03:00
$ hg log -r 2 -T '{if("1", "\\{rev}")} {if("1", r"\\{rev}")}\n'
templater: do not reevaluate rawstring as template (BC) The previous patch made 'string' is always interpreted as a template. So this patch removes the special handling of r'rawstring' instead. Now r'' disables template processing at all.
2015-06-10 15:44:43 +03:00
\2 \\{rev}
templater: do not preprocess template string in "if" expression (issue4714) The problem was spotted at cd1b50e99ed8, that says "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 workaround is no longer valid since 72be08a15d8d introduced strict parsing of '\{'. Instead, we should interpret bare token as "string" or "rawstring" template. This is what buildmap() does at parsing phase.
2015-06-08 12:14:22 +03:00
$ hg log -r 2 -T '{if("1", "\\\{rev}")} {if("1", r"\\\{rev}")}\n'
templater: do not reevaluate rawstring as template (BC) The previous patch made 'string' is always interpreted as a template. So this patch removes the special handling of r'rawstring' instead. Now r'' disables template processing at all.
2015-06-10 15:44:43 +03:00
\{rev} \\\{rev}
templater: do not preprocess template string in "if" expression (issue4714) The problem was spotted at cd1b50e99ed8, that says "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 workaround is no longer valid since 72be08a15d8d introduced strict parsing of '\{'. Instead, we should interpret bare token as "string" or "rawstring" template. This is what buildmap() does at parsing phase.
2015-06-08 12:14:22 +03:00
$ cd ..
templater: make strings in template expressions be "string-escape"-ed correctly Changeset 83ff877959a6 (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.
2014-03-09 20:01:43 +04:00
"string-escape"-ed "\x5c\x786e" becomes r"\x6e" (once) or r"n" (twice)
$ hg log -R a -r 0 --template '{if("1", "\x5c\x786e", "NG")}\n'
\x6e
$ hg log -R a -r 0 --template '{if("1", r"\x5c\x786e", "NG")}\n'
\x5c\x786e
$ hg log -R a -r 0 --template '{if("", "NG", "\x5c\x786e")}\n'
\x6e
$ hg log -R a -r 0 --template '{if("", "NG", r"\x5c\x786e")}\n'
\x5c\x786e
$ hg log -R a -r 2 --template '{ifeq("no perso\x6e", desc, "\x5c\x786e", "NG")}\n'
\x6e
$ hg log -R a -r 2 --template '{ifeq(r"no perso\x6e", desc, "NG", r"\x5c\x786e")}\n'
\x5c\x786e
$ hg log -R a -r 2 --template '{ifeq(desc, "no perso\x6e", "\x5c\x786e", "NG")}\n'
\x6e
$ hg log -R a -r 2 --template '{ifeq(desc, r"no perso\x6e", "NG", r"\x5c\x786e")}\n'
\x5c\x786e
$ hg log -R a -r 8 --template '{join(files, "\n")}\n'
fourth
second
third
$ hg log -R a -r 8 --template '{join(files, r"\n")}\n'
fourth\nsecond\nthird
$ hg log -R a -r 2 --template '{rstdoc("1st\n\n2nd", "htm\x6c")}'
<p>
1st
</p>
<p>
2nd
</p>
$ hg log -R a -r 2 --template '{rstdoc(r"1st\n\n2nd", "html")}'
<p>
1st\n\n2nd
</p>
$ hg log -R a -r 2 --template '{rstdoc("1st\n\n2nd", r"htm\x6c")}'
1st
2nd
$ hg log -R a -r 2 --template '{strip(desc, "\x6e")}\n'
o perso
$ hg log -R a -r 2 --template '{strip(desc, r"\x6e")}\n'
no person
$ hg log -R a -r 2 --template '{strip("no perso\x6e", "\x6e")}\n'
o perso
$ hg log -R a -r 2 --template '{strip(r"no perso\x6e", r"\x6e")}\n'
no perso
$ hg log -R a -r 2 --template '{sub("\\x6e", "\x2d", desc)}\n'
-o perso-
$ hg log -R a -r 2 --template '{sub(r"\\x6e", "-", desc)}\n'
no person
$ hg log -R a -r 2 --template '{sub("n", r"\x2d", desc)}\n'
\x2do perso\x2d
$ hg log -R a -r 2 --template '{sub("n", "\x2d", "no perso\x6e")}\n'
-o perso-
$ hg log -R a -r 2 --template '{sub("n", r"\x2d", r"no perso\x6e")}\n'
\x2do perso\x6e
$ hg log -R a -r 8 --template '{files % "{file}\n"}'
fourth
second
third
spelling: fixes from spell checker
2014-04-13 21:01:00 +04:00
Test string escaping in nested expression:
templater: make strings in template expressions be "string-escape"-ed correctly Changeset 83ff877959a6 (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.
2014-03-09 20:01:43 +04:00
$ hg log -R a -r 8 --template '{ifeq(r"\x6e", if("1", "\x5c\x786e"), join(files, "\x5c\x786e"))}\n'
fourth\x6esecond\x6ethird
$ hg log -R a -r 8 --template '{ifeq(if("1", r"\x6e"), "\x5c\x786e", join(files, "\x5c\x786e"))}\n'
fourth\x6esecond\x6ethird
$ hg log -R a -r 8 --template '{join(files, ifeq(branch, "default", "\x5c\x786e"))}\n'
fourth\x6esecond\x6ethird
$ hg log -R a -r 8 --template '{join(files, ifeq(branch, "default", r"\x5c\x786e"))}\n'
fourth\x5c\x786esecond\x5c\x786ethird
$ hg log -R a -r 3:4 --template '{rev}:{sub(if("1", "\x6e"), ifeq(branch, "foo", r"\x5c\x786e", "\x5c\x786e"), desc)}\n'
3:\x6eo user, \x6eo domai\x6e
4:\x5c\x786eew bra\x5c\x786ech
templater: introduce one-pass parsing of nested template strings Instead of re-parsing quoted strings as templates, the tokenizer can delegate the parsing of nested template strings to the parser. It has two benefits: 1. syntax errors can be reported with absolute positions 2. nested template can use quotes just like shell: "{"{rev}"}" It doesn't sound nice that the tokenizer recurses into the parser. We could instead make the tokenize itself recursive, but it would be much more complicated because we would have to adjust binding strengths carefully and put dummy infix operators to concatenate template fragments. Now "string" token without r"" never appears. It will be removed by the next patch.
2015-06-15 17:11:35 +03:00
Test quotes in nested expression are evaluated just like a $(command)
substitution in POSIX shells:
$ hg log -R a -r 8 -T '{"{"{rev}:{node|short}"}"}\n'
8:95c24699272e
$ hg log -R a -r 8 -T '{"{"\{{rev}} \"{node|short}\""}"}\n'
{8} "95c24699272e"
templater: only recursively evaluate string literals as templates (issue4103)
2013-11-19 00:37:09 +04:00
Test recursive evaluation:
$ hg init r
$ cd r
$ echo a > a
$ hg ci -Am '{rev}'
adding a
$ hg log -r 0 --template '{if(rev, desc)}\n'
{rev}
$ hg log -r 0 --template '{if(rev, "{author} {rev}")}\n'
test 0
templater: makes branches work correctly with stringify (issue4108)
2013-11-21 21:30:52 +04:00
templater: avoid recursive evaluation of string literals completely Changeset c84f81c3e120 (released with 2.8.1) fixed "recursively evaluate string literals as templates" problem (issue4103) by introducing "_evalifliteral()". But some parts in template expressions below are still processed by the combination of "compiletemplate()" and "runtemplate()", and may cause same problem unexpectedly. - 'init' and 'hang' of 'fill(text, width, init, hang)' - 'expr' of 'sub(pat, repl, expr)' - 'label' of 'label(label, expr)' This patch processes them by "_evalifliteral()" instead of the combination of "compiletemplate()" and "runtemplate()" to avoid recursive evaluation of string literals completely.
2014-03-09 20:01:42 +04:00
$ hg branch -q 'text.{rev}'
$ echo aa >> aa
$ hg ci -u '{node|short}' -m 'desc to be wrapped desc to be wrapped'
merge with stable
2014-03-12 01:19:08 +04:00
$ hg log -l1 --template '{fill(desc, "20", author, branch)}'
templater: avoid recursive evaluation of string literals completely Changeset c84f81c3e120 (released with 2.8.1) fixed "recursively evaluate string literals as templates" problem (issue4103) by introducing "_evalifliteral()". But some parts in template expressions below are still processed by the combination of "compiletemplate()" and "runtemplate()", and may cause same problem unexpectedly. - 'init' and 'hang' of 'fill(text, width, init, hang)' - 'expr' of 'sub(pat, repl, expr)' - 'label' of 'label(label, expr)' This patch processes them by "_evalifliteral()" instead of the combination of "compiletemplate()" and "runtemplate()" to avoid recursive evaluation of string literals completely.
2014-03-09 20:01:42 +04:00
{node|short}desc to
text.{rev}be wrapped
text.{rev}desc to be
text.{rev}wrapped (no-eol)
merge with stable
2014-03-12 01:19:08 +04:00
$ hg log -l1 --template '{fill(desc, "20", "{node|short}:", "text.{rev}:")}'
templater: avoid recursive evaluation of string literals completely Changeset c84f81c3e120 (released with 2.8.1) fixed "recursively evaluate string literals as templates" problem (issue4103) by introducing "_evalifliteral()". But some parts in template expressions below are still processed by the combination of "compiletemplate()" and "runtemplate()", and may cause same problem unexpectedly. - 'init' and 'hang' of 'fill(text, width, init, hang)' - 'expr' of 'sub(pat, repl, expr)' - 'label' of 'label(label, expr)' This patch processes them by "_evalifliteral()" instead of the combination of "compiletemplate()" and "runtemplate()" to avoid recursive evaluation of string literals completely.
2014-03-09 20:01:42 +04:00
bcc7ff960b8e:desc to
text.1:be wrapped
text.1:desc to be
text.1:wrapped (no-eol)
templater: drop redundant type conversion when evaluating integer argument A function argument may be an integer. In this case, it isn't necessary to convert a value to string and back to integer. Because an argument may be an arbitrary object (e.g. date tuple), TypeError should be caught as well.
2016-02-14 06:48:14 +03:00
$ hg log -l1 -T '{fill(desc, date, "", "")}\n'
hg: parse error: fill expects an integer width
[255]
templater: avoid recursive evaluation of string literals completely Changeset c84f81c3e120 (released with 2.8.1) fixed "recursively evaluate string literals as templates" problem (issue4103) by introducing "_evalifliteral()". But some parts in template expressions below are still processed by the combination of "compiletemplate()" and "runtemplate()", and may cause same problem unexpectedly. - 'init' and 'hang' of 'fill(text, width, init, hang)' - 'expr' of 'sub(pat, repl, expr)' - 'label' of 'label(label, expr)' This patch processes them by "_evalifliteral()" instead of the combination of "compiletemplate()" and "runtemplate()" to avoid recursive evaluation of string literals completely.
2014-03-09 20:01:42 +04:00
merge with stable
2014-03-12 01:19:08 +04:00
$ hg log -l 1 --template '{sub(r"[0-9]", "-", author)}'
templater: avoid recursive evaluation of string literals completely Changeset c84f81c3e120 (released with 2.8.1) fixed "recursively evaluate string literals as templates" problem (issue4103) by introducing "_evalifliteral()". But some parts in template expressions below are still processed by the combination of "compiletemplate()" and "runtemplate()", and may cause same problem unexpectedly. - 'init' and 'hang' of 'fill(text, width, init, hang)' - 'expr' of 'sub(pat, repl, expr)' - 'label' of 'label(label, expr)' This patch processes them by "_evalifliteral()" instead of the combination of "compiletemplate()" and "runtemplate()" to avoid recursive evaluation of string literals completely.
2014-03-09 20:01:42 +04:00
{node|short} (no-eol)
merge with stable
2014-03-12 01:19:08 +04:00
$ hg log -l 1 --template '{sub(r"[0-9]", "-", "{node|short}")}'
templater: avoid recursive evaluation of string literals completely Changeset c84f81c3e120 (released with 2.8.1) fixed "recursively evaluate string literals as templates" problem (issue4103) by introducing "_evalifliteral()". But some parts in template expressions below are still processed by the combination of "compiletemplate()" and "runtemplate()", and may cause same problem unexpectedly. - 'init' and 'hang' of 'fill(text, width, init, hang)' - 'expr' of 'sub(pat, repl, expr)' - 'label' of 'label(label, expr)' This patch processes them by "_evalifliteral()" instead of the combination of "compiletemplate()" and "runtemplate()" to avoid recursive evaluation of string literals completely.
2014-03-09 20:01:42 +04:00
bcc-ff---b-e (no-eol)
$ cat >> .hg/hgrc <<EOF
> [extensions]
> color=
> [color]
> mode=ansi
> text.{rev} = red
> text.1 = green
> EOF
merge with stable
2014-03-12 01:19:08 +04:00
$ hg log --color=always -l 1 --template '{label(branch, "text\n")}'
templater: avoid recursive evaluation of string literals completely Changeset c84f81c3e120 (released with 2.8.1) fixed "recursively evaluate string literals as templates" problem (issue4103) by introducing "_evalifliteral()". But some parts in template expressions below are still processed by the combination of "compiletemplate()" and "runtemplate()", and may cause same problem unexpectedly. - 'init' and 'hang' of 'fill(text, width, init, hang)' - 'expr' of 'sub(pat, repl, expr)' - 'label' of 'label(label, expr)' This patch processes them by "_evalifliteral()" instead of the combination of "compiletemplate()" and "runtemplate()" to avoid recursive evaluation of string literals completely.
2014-03-09 20:01:42 +04:00
\x1b[0;31mtext\x1b[0m (esc)
merge with stable
2014-03-12 01:19:08 +04:00
$ hg log --color=always -l 1 --template '{label("text.{rev}", "text\n")}'
templater: avoid recursive evaluation of string literals completely Changeset c84f81c3e120 (released with 2.8.1) fixed "recursively evaluate string literals as templates" problem (issue4103) by introducing "_evalifliteral()". But some parts in template expressions below are still processed by the combination of "compiletemplate()" and "runtemplate()", and may cause same problem unexpectedly. - 'init' and 'hang' of 'fill(text, width, init, hang)' - 'expr' of 'sub(pat, repl, expr)' - 'label' of 'label(label, expr)' This patch processes them by "_evalifliteral()" instead of the combination of "compiletemplate()" and "runtemplate()" to avoid recursive evaluation of string literals completely.
2014-03-09 20:01:42 +04:00
\x1b[0;32mtext\x1b[0m (esc)
templater: make label() take unknown symbol as color literal Instead of the mapping hack introduced by d4686e0c15c9, this patch changes the way how a label symbol is evaluated. This is still hackish, but should be more predictable in that it doesn't depend on the known color effects. This change is intended to eliminate the reference to color._effects so that color.templatelabel() can be merged with templater.label().
2015-06-11 16:58:27 +03:00
color effect can be specified without quoting:
$ hg log --color=always -l 1 --template '{label(red, "text\n")}'
\x1b[0;31mtext\x1b[0m (esc)
templater: move label() function from color extension ui.label() is no-op by default, so we can just call ui.label() by label() template function no matter if the color is enabled or not.
2015-06-11 17:04:14 +03:00
label should be no-op if color is disabled:
$ hg log --color=never -l 1 --template '{label(red, "text\n")}'
text
$ hg log --config extensions.color=! -l 1 --template '{label(red, "text\n")}'
text
templater: makes branches work correctly with stringify (issue4108)
2013-11-21 21:30:52 +04:00
Test branches inside if statement:
$ hg log -r 0 --template '{if(branches, "yes", "no")}\n'
no
template: add shortest(node) template function Adds a '{shortest(node)}' template function that results in the shortest hex node that uniquely identifies the changeset at that time. The minimum length can be specified as an optional second argument and defaults to 4. This is useful for producing prettier log output, like so: @ durham shortestnode | 77cf template: add pad function for padding output | o durham | b183 template: add shortestnode keyword | o pierre-yves @ | 6545 backout: add a message after backout that need manual commit | | o durham manifestcache |/ 93f0 manifest cache | | o durham catperf | | c765 cat: increase perf when catting single files | | | o durham |/ 9c53 changectx: increase perf of walk function |
2014-01-17 12:10:37 +04:00
templatekw: forward _hybrid.get to raw values so that get(extras, key) works fffa7616be9d implies that the primary goal is to allow "{get(extras, key)}", but it didn't work. I'm not sure if _hybrid should forward all unknown attributes to values, so only "get" is forwarded for now.
2015-02-18 17:17:52 +03:00
Test get function:
$ hg log -r 0 --template '{get(extras, "branch")}\n'
default
templater: fix get() to evaluate arguments eagerly If a key is constructed from a template expression, it may be a generator. In that case, a key have to be stringified. A dictarg should never be a generator, but this patch also changes it to call evalfuncarg() for consistency.
2016-02-13 18:05:58 +03:00
$ hg log -r 0 --template '{get(extras, "br{"anch"}")}\n'
default
templatekw: forward _hybrid.get to raw values so that get(extras, key) works fffa7616be9d implies that the primary goal is to allow "{get(extras, key)}", but it didn't work. I'm not sure if _hybrid should forward all unknown attributes to values, so only "get" is forwarded for now.
2015-02-18 17:17:52 +03:00
$ hg log -r 0 --template '{get(files, "should_fail")}\n'
hg: parse error: get() expects a dict as first argument
[255]
templater: add optional timezone argument to localdate() The keyword extension uses "utcdate" for a different function, so we can't add new "utcdate" filter or function. Instead, this patch extends "localdate" to a general timezone converter.
2015-08-18 16:15:46 +03:00
Test localdate(date, tz) function:
$ TZ=JST-09 hg log -r0 -T '{date|localdate|isodate}\n'
1970-01-01 09:00 +0900
$ TZ=JST-09 hg log -r0 -T '{localdate(date, "UTC")|isodate}\n'
1970-01-01 00:00 +0000
$ TZ=JST-09 hg log -r0 -T '{localdate(date, "+0200")|isodate}\n'
1970-01-01 02:00 +0200
$ TZ=JST-09 hg log -r0 -T '{localdate(date, "0")|isodate}\n'
1970-01-01 00:00 +0000
$ TZ=JST-09 hg log -r0 -T '{localdate(date, 0)|isodate}\n'
1970-01-01 00:00 +0000
$ hg log -r0 -T '{localdate(date, "invalid")|isodate}\n'
hg: parse error: localdate expects a timezone
[255]
$ hg log -r0 -T '{localdate(date, date)|isodate}\n'
hg: parse error: localdate expects a timezone
[255]
template: add shortest(node) template function Adds a '{shortest(node)}' template function that results in the shortest hex node that uniquely identifies the changeset at that time. The minimum length can be specified as an optional second argument and defaults to 4. This is useful for producing prettier log output, like so: @ durham shortestnode | 77cf template: add pad function for padding output | o durham | b183 template: add shortestnode keyword | o pierre-yves @ | 6545 backout: add a message after backout that need manual commit | | o durham manifestcache |/ 93f0 manifest cache | | o durham catperf | | c765 cat: increase perf when catting single files | | | o durham |/ 9c53 changectx: increase perf of walk function |
2014-01-17 12:10:37 +04:00
Test shortest(node) function:
$ echo b > b
$ hg ci -qAm b
$ hg log --template '{shortest(node)}\n'
merge with stable
2014-03-12 01:19:08 +04:00
e777
bcc7
template: add shortest(node) template function Adds a '{shortest(node)}' template function that results in the shortest hex node that uniquely identifies the changeset at that time. The minimum length can be specified as an optional second argument and defaults to 4. This is useful for producing prettier log output, like so: @ durham shortestnode | 77cf template: add pad function for padding output | o durham | b183 template: add shortestnode keyword | o pierre-yves @ | 6545 backout: add a message after backout that need manual commit | | o durham manifestcache |/ 93f0 manifest cache | | o durham catperf | | c765 cat: increase perf when catting single files | | | o durham |/ 9c53 changectx: increase perf of walk function |
2014-01-17 12:10:37 +04:00
f776
$ hg log --template '{shortest(node, 10)}\n'
merge with stable
2014-03-12 01:19:08 +04:00
e777603221
bcc7ff960b
template: add shortest(node) template function Adds a '{shortest(node)}' template function that results in the shortest hex node that uniquely identifies the changeset at that time. The minimum length can be specified as an optional second argument and defaults to 4. This is useful for producing prettier log output, like so: @ durham shortestnode | 77cf template: add pad function for padding output | o durham | b183 template: add shortestnode keyword | o pierre-yves @ | 6545 backout: add a message after backout that need manual commit | | o durham manifestcache |/ 93f0 manifest cache | | o durham catperf | | c765 cat: increase perf when catting single files | | | o durham |/ 9c53 changectx: increase perf of walk function |
2014-01-17 12:10:37 +04:00
f7769ec2ab
templater: introduce unified filter syntax for unary functions "filter(expr)" is allowed already. This patch adds the opposite, "expr|func".
2015-07-04 10:03:36 +03:00
$ hg log --template '{node|shortest}\n' -l1
e777
template: add pad function for padding output Adds a pad template function with the following signature: pad(text, width, fillchar=' ', right=False) This uses the standard python ljust and rjust functions to produce a string that is at least a certain width. This is useful for aligning variable length strings in log output (like user names or shortest(node) output).
2014-01-17 12:16:48 +04:00
templater: fix shortest() to evaluate int argument and handle error
2016-02-14 07:09:17 +03:00
$ hg log -r 0 -T '{shortest(node, "1{"0"}")}\n'
f7769ec2ab
$ hg log -r 0 -T '{shortest(node, "not an int")}\n'
hg: parse error: shortest() expects an integer minlength
[255]
template: add pad function for padding output Adds a pad template function with the following signature: pad(text, width, fillchar=' ', right=False) This uses the standard python ljust and rjust functions to produce a string that is at least a certain width. This is useful for aligning variable length strings in log output (like user names or shortest(node) output).
2014-01-17 12:16:48 +04:00
Test pad function
$ hg log --template '{pad(rev, 20)} {author|user}\n'
merge with stable
2014-03-12 01:19:08 +04:00
2 test
1 {node|short}
template: add pad function for padding output Adds a pad template function with the following signature: pad(text, width, fillchar=' ', right=False) This uses the standard python ljust and rjust functions to produce a string that is at least a certain width. This is useful for aligning variable length strings in log output (like user names or shortest(node) output).
2014-01-17 12:16:48 +04:00
0 test
$ hg log --template '{pad(rev, 20, " ", True)} {author|user}\n'
merge with stable
2014-03-12 01:19:08 +04:00
2 test
1 {node|short}
template: add pad function for padding output Adds a pad template function with the following signature: pad(text, width, fillchar=' ', right=False) This uses the standard python ljust and rjust functions to produce a string that is at least a certain width. This is useful for aligning variable length strings in log output (like user names or shortest(node) output).
2014-01-17 12:16:48 +04:00
0 test
$ hg log --template '{pad(rev, 20, "-", False)} {author|user}\n'
merge with stable
2014-03-12 01:19:08 +04:00
2------------------- test
1------------------- {node|short}
template: add pad function for padding output Adds a pad template function with the following signature: pad(text, width, fillchar=' ', right=False) This uses the standard python ljust and rjust functions to produce a string that is at least a certain width. This is useful for aligning variable length strings in log output (like user names or shortest(node) output).
2014-01-17 12:16:48 +04:00
0------------------- test
template: add ifcontains template function Adds a template function with the signature 'ifcontains(item, set, then[, else])'. It can be used to do things like '{ifcontains('.hgignore', file_mods, label(...), ...)}' to color commits that edit the .hgignore file. A future patch will add the revset() function which will combine with ifcontains to allow us to color commits if they are in the revset.
2014-02-12 09:10:00 +04:00
templater: make pad function evaluate both string and rawstring templates "pad" function and "rawstring" type were introduced in parallel, 89145c35f76e in default and cd1b50e99ed8 in stable respectively. Therefore, "pad" function lacked handling of "rawstring" unintentionally.
2015-06-08 12:48:45 +03:00
Test template string in pad function
$ hg log -r 0 -T '{pad("\{{rev}}", 10)} {author|user}\n'
{0} test
$ hg log -r 0 -T '{pad(r"\{rev}", 10)} {author|user}\n'
templater: do not reevaluate rawstring as template (BC) The previous patch made 'string' is always interpreted as a template. So this patch removes the special handling of r'rawstring' instead. Now r'' disables template processing at all.
2015-06-10 15:44:43 +03:00
\{rev} test
templater: make pad function evaluate both string and rawstring templates "pad" function and "rawstring" type were introduced in parallel, 89145c35f76e in default and cd1b50e99ed8 in stable respectively. Therefore, "pad" function lacked handling of "rawstring" unintentionally.
2015-06-08 12:48:45 +03:00
templater: fix pad() to evaluate int argument and handle error
2016-02-14 07:05:09 +03:00
Test width argument passed to pad function
$ hg log -r 0 -T '{pad(rev, "1{"0"}")} {author|user}\n'
0 test
$ hg log -r 0 -T '{pad(rev, "not an int")}\n'
hg: parse error: pad() expects an integer width
[255]
template: add ifcontains template function Adds a template function with the signature 'ifcontains(item, set, then[, else])'. It can be used to do things like '{ifcontains('.hgignore', file_mods, label(...), ...)}' to color commits that edit the .hgignore file. A future patch will add the revset() function which will combine with ifcontains to allow us to color commits if they are in the revset.
2014-02-12 09:10:00 +04:00
Test ifcontains function
templater: fix ifcontains when list is a string (issue4399)
2014-10-10 20:38:00 +04:00
$ hg log --template '{rev} {ifcontains(rev, "2 two 0", "is in the string", "is not")}\n'
2 is in the string
1 is not
0 is in the string
templater: fix ifcontains() to evaluate items argument eagerly See the previous patch for why. An "items" argument may be a string, a generator, or an arbitrary container object.
2016-02-13 18:18:12 +03:00
$ hg log -T '{rev} {ifcontains(rev, "2 two{" 0"}", "is in the string", "is not")}\n'
2 is in the string
1 is not
0 is in the string
template: add ifcontains template function Adds a template function with the signature 'ifcontains(item, set, then[, else])'. It can be used to do things like '{ifcontains('.hgignore', file_mods, label(...), ...)}' to color commits that edit the .hgignore file. A future patch will add the revset() function which will combine with ifcontains to allow us to color commits if they are in the revset.
2014-02-12 09:10:00 +04:00
$ hg log --template '{rev} {ifcontains("a", file_adds, "added a", "did not add a")}\n'
merge with stable
2014-03-12 01:19:08 +04:00
2 did not add a
template: add ifcontains template function Adds a template function with the signature 'ifcontains(item, set, then[, else])'. It can be used to do things like '{ifcontains('.hgignore', file_mods, label(...), ...)}' to color commits that edit the .hgignore file. A future patch will add the revset() function which will combine with ifcontains to allow us to color commits if they are in the revset.
2014-02-12 09:10:00 +04:00
1 did not add a
0 added a
template: add revset() template function Adds a template function that executes a revset and returns the list of revisions as the result. It has the signature 'revset(query [, args...])'. The args are optional and are applied to the query string using the standard python string.format(args) pattern. This allows things like: '{revset("parents({0})", rev)}' to produce the parents of each individual commit in the log output. If no args are specified, the revset result is cached for the duration of the templater; so it's better to not use args if performance is a concern. By itself, revset() can be used to print commit parents, print the common ancestor of a commit with the main branch, etc. It can be used with the ifcontains() function to do things like '{ifcontains(rev, revset('.'), label(...), ...)}' to color the working copy parent, to color certain branches, to color draft commits, etc.
2014-02-12 09:04:12 +04:00
templatekw: switch ctx of list expression to rev of {parents} (BC) This is the same semantics as revset() introduced at eef3c19484ca. Before this patch, {parents} provided nothing useful in new-style template. For example, '{parents % "{parent}"}' generated cryptic string like "rev12345node0123abcdef...". This patch drops {parent} variable since it was useless. We can get a revision number by '{parents % "{rev}"}'.
2016-02-12 13:16:09 +03:00
$ hg log --debug -T '{rev}{ifcontains(1, parents, " is parent of 1")}\n'
2 is parent of 1
1
0
template: add revset() template function Adds a template function that executes a revset and returns the list of revisions as the result. It has the signature 'revset(query [, args...])'. The args are optional and are applied to the query string using the standard python string.format(args) pattern. This allows things like: '{revset("parents({0})", rev)}' to produce the parents of each individual commit in the log output. If no args are specified, the revset result is cached for the duration of the templater; so it's better to not use args if performance is a concern. By itself, revset() can be used to print commit parents, print the common ancestor of a commit with the main branch, etc. It can be used with the ifcontains() function to do things like '{ifcontains(rev, revset('.'), label(...), ...)}' to color the working copy parent, to color certain branches, to color draft commits, etc.
2014-02-12 09:04:12 +04:00
Test revset function
$ hg log --template '{rev} {ifcontains(rev, revset("."), "current rev", "not current rev")}\n'
merge with stable
2014-03-12 01:19:08 +04:00
2 current rev
1 not current rev
template: add revset() template function Adds a template function that executes a revset and returns the list of revisions as the result. It has the signature 'revset(query [, args...])'. The args are optional and are applied to the query string using the standard python string.format(args) pattern. This allows things like: '{revset("parents({0})", rev)}' to produce the parents of each individual commit in the log output. If no args are specified, the revset result is cached for the duration of the templater; so it's better to not use args if performance is a concern. By itself, revset() can be used to print commit parents, print the common ancestor of a commit with the main branch, etc. It can be used with the ifcontains() function to do things like '{ifcontains(rev, revset('.'), label(...), ...)}' to color the working copy parent, to color certain branches, to color draft commits, etc.
2014-02-12 09:04:12 +04:00
0 not current rev
templates: fix ifcontains against sets with length > 1 (issue4259) Previously the ifcontains revset was checking against the set using a pure __contains__ check. It turns out the set was actually a list of formatted strings meant for ui output, which meant the contains check failed if the formatted string wasn't significantly different from the raw value. This change makes it check against the raw data, prior to it being formatted.
2014-05-24 03:25:55 +04:00
$ hg log --template '{rev} {ifcontains(rev, revset(". + .^"), "match rev", "not match rev")}\n'
2 match rev
1 match rev
0 not match rev
template: add revset() template function Adds a template function that executes a revset and returns the list of revisions as the result. It has the signature 'revset(query [, args...])'. The args are optional and are applied to the query string using the standard python string.format(args) pattern. This allows things like: '{revset("parents({0})", rev)}' to produce the parents of each individual commit in the log output. If no args are specified, the revset result is cached for the duration of the templater; so it's better to not use args if performance is a concern. By itself, revset() can be used to print commit parents, print the common ancestor of a commit with the main branch, etc. It can be used with the ifcontains() function to do things like '{ifcontains(rev, revset('.'), label(...), ...)}' to color the working copy parent, to color certain branches, to color draft commits, etc.
2014-02-12 09:04:12 +04:00
$ hg log --template '{rev} Parents: {revset("parents(%s)", rev)}\n'
merge with stable
2014-03-12 01:19:08 +04:00
2 Parents: 1
template: add revset() template function Adds a template function that executes a revset and returns the list of revisions as the result. It has the signature 'revset(query [, args...])'. The args are optional and are applied to the query string using the standard python string.format(args) pattern. This allows things like: '{revset("parents({0})", rev)}' to produce the parents of each individual commit in the log output. If no args are specified, the revset result is cached for the duration of the templater; so it's better to not use args if performance is a concern. By itself, revset() can be used to print commit parents, print the common ancestor of a commit with the main branch, etc. It can be used with the ifcontains() function to do things like '{ifcontains(rev, revset('.'), label(...), ...)}' to color the working copy parent, to color certain branches, to color draft commits, etc.
2014-02-12 09:04:12 +04:00
1 Parents: 0
0 Parents:
templater: enable alias predicates to be used in "revset()" function Before this patch, predicates defined in "[revsetalias]" can't be used in the query specified to template function "revset()", because: - "revset()" uses "localrepository.revs()" to get query result, but - "localrepository.revs()" passes "None" as "ui" to "revset.match()", then - "revset.match()" can't recognize any alias predicates To enable alias predicates to be used in "revset()" function, this patch invokes "revset.match()" directly with "repo.ui". This patch doesn't make "localrepository.revs()" pass "self.ui" to "revset.match()", because this may be intentional implementation to prevent alias predicates from shadowing built-in ones and breaking functions internally using "localrepository.revs()". Even if it isn't intentional one, the check for shadowing should be implemented (maybe on default branch) before fixing it for safety.
2014-08-23 16:23:02 +04:00
$ cat >> .hg/hgrc <<EOF
> [revsetalias]
> myparents(\$1) = parents(\$1)
> EOF
$ hg log --template '{rev} Parents: {revset("myparents(%s)", rev)}\n'
2 Parents: 1
1 Parents: 0
0 Parents:
template: add revset() template function Adds a template function that executes a revset and returns the list of revisions as the result. It has the signature 'revset(query [, args...])'. The args are optional and are applied to the query string using the standard python string.format(args) pattern. This allows things like: '{revset("parents({0})", rev)}' to produce the parents of each individual commit in the log output. If no args are specified, the revset result is cached for the duration of the templater; so it's better to not use args if performance is a concern. By itself, revset() can be used to print commit parents, print the common ancestor of a commit with the main branch, etc. It can be used with the ifcontains() function to do things like '{ifcontains(rev, revset('.'), label(...), ...)}' to color the working copy parent, to color certain branches, to color draft commits, etc.
2014-02-12 09:04:12 +04:00
$ hg log --template 'Rev: {rev}\n{revset("::%s", rev) % "Ancestor: {revision}\n"}\n'
merge with stable
2014-03-12 01:19:08 +04:00
Rev: 2
Ancestor: 0
Ancestor: 1
Ancestor: 2
template: add revset() template function Adds a template function that executes a revset and returns the list of revisions as the result. It has the signature 'revset(query [, args...])'. The args are optional and are applied to the query string using the standard python string.format(args) pattern. This allows things like: '{revset("parents({0})", rev)}' to produce the parents of each individual commit in the log output. If no args are specified, the revset result is cached for the duration of the templater; so it's better to not use args if performance is a concern. By itself, revset() can be used to print commit parents, print the common ancestor of a commit with the main branch, etc. It can be used with the ifcontains() function to do things like '{ifcontains(rev, revset('.'), label(...), ...)}' to color the working copy parent, to color certain branches, to color draft commits, etc.
2014-02-12 09:04:12 +04:00
Rev: 1
Ancestor: 0
Ancestor: 1
Rev: 0
Ancestor: 0
templater: evaluate "query" argument passed to revset() revset() had the same issue as f921aa09b251. It crashed by passing non-string expression.
2015-06-20 17:13:34 +03:00
$ hg log --template '{revset("TIP"|lower)}\n' -l1
2
templater: fix revset() to evaluate format arguments eagerly See the previous patch for why. This patch also removes redundant list() construction from a list.
2016-02-13 18:27:09 +03:00
$ hg log -T '{revset("%s", "t{"ip"}")}\n' -l1
2
templatekw: switch ctx of list expression to rev of {parents} (BC) This is the same semantics as revset() introduced at eef3c19484ca. Before this patch, {parents} provided nothing useful in new-style template. For example, '{parents % "{parent}"}' generated cryptic string like "rev12345node0123abcdef...". This patch drops {parent} variable since it was useless. We can get a revision number by '{parents % "{rev}"}'.
2016-02-12 13:16:09 +03:00
a list template is evaluated for each item of revset/parents
templater: switch ctx of list expression to rev of revset() (BC) Because revset() function generates a list of revisions, it seems sensible to switch the ctx as well where a list expression will be evaluated. I think "{revset(...) % "..."}" expression wasn't considered well when it was introduced at 45e0e191755f.
2015-09-11 18:21:41 +03:00
$ hg log -T '{rev} p: {revset("p1(%s)", rev) % "{rev}:{node|short}"}\n'
2 p: 1:bcc7ff960b8e
1 p: 0:f7769ec2ab97
0 p:
templatekw: switch ctx of list expression to rev of {parents} (BC) This is the same semantics as revset() introduced at eef3c19484ca. Before this patch, {parents} provided nothing useful in new-style template. For example, '{parents % "{parent}"}' generated cryptic string like "rev12345node0123abcdef...". This patch drops {parent} variable since it was useless. We can get a revision number by '{parents % "{rev}"}'.
2016-02-12 13:16:09 +03:00
$ hg log --debug -T '{rev} p:{parents % " {rev}:{node|short}"}\n'
2 p: 1:bcc7ff960b8e -1:000000000000
1 p: 0:f7769ec2ab97 -1:000000000000
0 p: -1:000000000000 -1:000000000000
templater: switch ctx of list expression to rev of revset() (BC) Because revset() function generates a list of revisions, it seems sensible to switch the ctx as well where a list expression will be evaluated. I think "{revset(...) % "..."}" expression wasn't considered well when it was introduced at 45e0e191755f.
2015-09-11 18:21:41 +03:00
therefore, 'revcache' should be recreated for each rev
$ hg log -T '{rev} {file_adds}\np {revset("p1(%s)", rev) % "{file_adds}"}\n'
2 aa b
p
1
p a
0 a
p
templatekw: switch ctx of list expression to rev of {parents} (BC) This is the same semantics as revset() introduced at eef3c19484ca. Before this patch, {parents} provided nothing useful in new-style template. For example, '{parents % "{parent}"}' generated cryptic string like "rev12345node0123abcdef...". This patch drops {parent} variable since it was useless. We can get a revision number by '{parents % "{rev}"}'.
2016-02-12 13:16:09 +03:00
$ hg log --debug -T '{rev} {file_adds}\np {parents % "{file_adds}"}\n'
2 aa b
p
1
p a
0 a
p
templater: evaluate each item of revset() as integer revision Because templater.revset() returns a list of strings, repo["-1"] was mapped to the tipmost revision. Ideally, we should make revset() return a list of integer revisions, but it turned out not simple. If revset() is a list of integers, "{ifcontains(rev, revset(), ...)}" would fail because "ifcontains" casts "rev" to a string. So this patch just converts a string back to an integer revision.
2016-02-12 12:08:53 +03:00
a revset item must be evaluated as an integer revision, not an offset from tip
$ hg log -l 1 -T '{revset("null") % "{rev}:{node|short}"}\n'
-1:000000000000
$ hg log -l 1 -T '{revset("%s", "null") % "{rev}:{node|short}"}\n'
-1:000000000000
commands: rename current to active in variables and comments Today, the terms 'active' and 'current' are interchangeably used throughout the codebase in reference to the active bookmark (the bookmark that will be updated with the next commit). This leads to confusion among developers and users. This patch is part of a series to standardize the usage to 'active' throughout the mercurial codebase and user interface.
2015-05-29 06:06:19 +03:00
Test active bookmark templating
template: add 'current' to scope during {bookmarks % ...} This adds the keyword 'current' to the template scope when processing a bookmark list. The 'current' keyword resolves to the name of the currently active bookmark in the repo. This allows us to apply special labels to the current bookmark to distinguish it (especially in the case where there are multiple bookmarks on the same commit). Example: "{bookmarks % '{bookmark}{ifeq(bookmark, current, \"*\")} '}" Results in a space separated list of bookmarks where the current bookmark has an asterix.
2014-02-12 09:40:33 +04:00
$ hg book foo
$ hg book bar
templatekw: introduce active subkeyword from bookmarks keyword Today, the terms 'active' and 'current' are interchangeably used throughout the codebase in reference to the active bookmark (the bookmark that will be updated with the next commit). This leads to confusion among developers and users. This patch is part of a series to standardize the usage to 'active' throughout the mercurial codebase and user interface.
2015-05-29 06:03:42 +03:00
$ hg log --template "{rev} {bookmarks % '{bookmark}{ifeq(bookmark, active, \"*\")} '}\n"
merge with stable
2014-03-12 01:19:08 +04:00
2 bar* foo
1
template: add 'current' to scope during {bookmarks % ...} This adds the keyword 'current' to the template scope when processing a bookmark list. The 'current' keyword resolves to the name of the currently active bookmark in the repo. This allows us to apply special labels to the current bookmark to distinguish it (especially in the case where there are multiple bookmarks on the same commit). Example: "{bookmarks % '{bookmark}{ifeq(bookmark, current, \"*\")} '}" Results in a space separated list of bookmarks where the current bookmark has an asterix.
2014-02-12 09:40:33 +04:00
0
templatekw: replace currentbookmark with activebookmark keyword Today, the terms 'active' and 'current' are interchangeably used throughout the codebase in reference to the active bookmark (the bookmark that will be updated with the next commit). This leads to confusion among developers and users. This patch is part of a series to standardize the usage to 'active' throughout the mercurial codebase and user interface.
2015-04-15 18:19:36 +03:00
$ hg log --template "{rev} {activebookmark}\n"
templatekw: add 'currentbookmark' keyword to show current bookmark easily Before this patch, complicated template expression below is required to show current active bookmark if it is associated with the changeset. "{bookmarks % '{ifeq(bookmark, current, \"{bookmark}\")}'}" This patch add 'currentbookmark' keyword to show current bookmark easily.
2014-07-15 18:34:13 +04:00
2 bar
1
0
$ hg bookmarks --inactive bar
templatekw: replace currentbookmark with activebookmark keyword Today, the terms 'active' and 'current' are interchangeably used throughout the codebase in reference to the active bookmark (the bookmark that will be updated with the next commit). This leads to confusion among developers and users. This patch is part of a series to standardize the usage to 'active' throughout the mercurial codebase and user interface.
2015-04-15 18:19:36 +03:00
$ hg log --template "{rev} {activebookmark}\n"
templatekw: add 'currentbookmark' keyword to show current bookmark easily Before this patch, complicated template expression below is required to show current active bookmark if it is associated with the changeset. "{bookmarks % '{ifeq(bookmark, current, \"{bookmark}\")}'}" This patch add 'currentbookmark' keyword to show current bookmark easily.
2014-07-15 18:34:13 +04:00
2
1
0
templatekw: fix {join(bookmarks, sep)} to always show associated bookmarks The default joinfmt, "x.values()[0]", can't be used here because it picks either 'bookmark' or 'current' randomly. I got wrong result with PYTHONHASHSEED=1 on my amd64 machine.
2015-02-18 16:17:35 +03:00
$ hg book -r1 baz
$ hg log --template "{rev} {join(bookmarks, ' ')}\n"
2 bar foo
1 baz
0
templater: implement _hybrid.__contains__ so that ifcontains can accept dict 7678263f920c is fine for "{revset()}", but "i.values()[0]" does not work if each item has more than one values such as "{bookmarks}". This fixes the problem by using list.__contains__ or dict.__contains__ appropriately.
2015-02-18 17:01:33 +03:00
$ hg log --template "{rev} {ifcontains('foo', bookmarks, 't', 'f')}\n"
2 t
1 f
0 f
templater: apply "stringify()" on sub expression to get string correctly Templating syntax allows nested expression to be specified as parts below, but they are evaluated as a generator and don't work correctly. - 'sep' of 'join(list, sep)' - 'text' and 'chars' of 'strip(text, chars)' In the former case, 'sep' returns expected string only for the first separation, and empty one for the second or later, because the generator has only one element. In the latter case, templating is aborted by exception, because the generator doesn't have 'strip()' method (as 'text') and can't be passed as the argument to 'str.strip()' (as 'chars'). This patch applies "stringify()" on these sub expression to get string correctly.
2014-03-09 20:01:43 +04:00
templatekw: add {namespaces} keyword This provides a general-purpose interface to all custom namespaces. The {namespaces} keyword honors the definition order of namespaces as they are kept by sortdict.
2016-01-12 17:56:48 +03:00
Test namespaces dict
$ hg log -T '{rev}{namespaces % " {namespace}={join(names, ",")}"}\n'
2 bookmarks=bar,foo tags=tip branches=text.{rev}
1 bookmarks=baz tags= branches=text.{rev}
0 bookmarks= tags= branches=default
$ hg log -r2 -T '{namespaces % "{namespace}: {names}\n"}'
bookmarks: bar foo
tags: tip
branches: text.{rev}
$ hg log -r2 -T '{namespaces % "{namespace}:\n{names % " {name}\n"}"}'
bookmarks:
bar
foo
tags:
tip
branches:
text.{rev}
$ hg log -r2 -T '{get(namespaces, "bookmarks") % "{name}\n"}'
bar
foo
templater: apply "stringify()" on sub expression to get string correctly Templating syntax allows nested expression to be specified as parts below, but they are evaluated as a generator and don't work correctly. - 'sep' of 'join(list, sep)' - 'text' and 'chars' of 'strip(text, chars)' In the former case, 'sep' returns expected string only for the first separation, and empty one for the second or later, because the generator has only one element. In the latter case, templating is aborted by exception, because the generator doesn't have 'strip()' method (as 'text') and can't be passed as the argument to 'str.strip()' (as 'chars'). This patch applies "stringify()" on these sub expression to get string correctly.
2014-03-09 20:01:43 +04:00
Test stringify on sub expressions
merge with stable
2014-03-12 01:19:08 +04:00
$ cd ..
templater: apply "stringify()" on sub expression to get string correctly Templating syntax allows nested expression to be specified as parts below, but they are evaluated as a generator and don't work correctly. - 'sep' of 'join(list, sep)' - 'text' and 'chars' of 'strip(text, chars)' In the former case, 'sep' returns expected string only for the first separation, and empty one for the second or later, because the generator has only one element. In the latter case, templating is aborted by exception, because the generator doesn't have 'strip()' method (as 'text') and can't be passed as the argument to 'str.strip()' (as 'chars'). This patch applies "stringify()" on these sub expression to get string correctly.
2014-03-09 20:01:43 +04:00
$ hg log -R a -r 8 --template '{join(files, if("1", if("1", ", ")))}\n'
fourth, second, third
$ hg log -R a -r 8 --template '{strip(if("1", if("1", "-abc-")), if("1", if("1", "-")))}\n'
abc
merge with stable
2014-03-12 01:19:08 +04:00
templatefilter: add splitlines function This is useful for applying changes to each line, and it's especially powerful when used in conjunction with conditionals to modify lines based on content.
2014-06-13 04:45:41 +04:00
Test splitlines
$ hg log -Gv -R a --template "{splitlines(desc) % 'foo {line}\n'}"
tests: add a new commit to test-commandline-template This commit modifies, adds, renames, removes files all at once. It will be mostly interesting for an upcoming test relating to the status log template.
2015-05-05 21:45:09 +03:00
@ foo Modify, add, remove, rename
|
o foo future
templatefilter: add splitlines function This is useful for applying changes to each line, and it's especially powerful when used in conjunction with conditionals to modify lines based on content.
2014-06-13 04:45:41 +04:00
|
o foo third
|
o foo second
o foo merge
|\
| o foo new head
| |
o | foo new branch
|/
o foo no user, no domain
|
o foo no person
|
o foo other 1
| foo other 2
| foo
| foo other 3
o foo line 1
foo line 2
templater: introduce startswith function This function returns a string only if it starts with a given string. It is particularly useful when combined with splitlines and/or used with conditionals that fail when empty strings are passed in to take action based on the contents of a line.
2014-06-13 04:53:37 +04:00
Test startswith
$ hg log -Gv -R a --template "{startswith(desc)}"
hg: parse error: startswith expects two arguments
[255]
$ hg log -Gv -R a --template "{startswith('line', desc)}"
@
|
o
|
o
tests: add a new commit to test-commandline-template This commit modifies, adds, renames, removes files all at once. It will be mostly interesting for an upcoming test relating to the status log template.
2015-05-05 21:45:09 +03:00
|
o
templater: introduce startswith function This function returns a string only if it starts with a given string. It is particularly useful when combined with splitlines and/or used with conditionals that fail when empty strings are passed in to take action based on the contents of a line.
2014-06-13 04:53:37 +04:00
o
|\
| o
| |
o |
|/
o
|
o
|
o
|
o line 1
line 2
templater: add symbol to error This patch makes it easier to debug writing templater functions by telling the user exactly what was sent to the templater.
2014-06-13 05:07:21 +04:00
Test bad template with better error message
$ hg log -Gv -R a --template '{desc|user()}'
hg: parse error: expected a symbol, got 'func'
[255]
templater: introduce word function This function allows returning only the nth "word" from a string. By default a string is split as by Python's split() function default, but an optional third parameter can also override what string the string is split by.
2014-06-13 05:02:23 +04:00
Test word function (including index out of bounds graceful failure)
$ hg log -Gv -R a --template "{word('1', desc)}"
tests: add a new commit to test-commandline-template This commit modifies, adds, renames, removes files all at once. It will be mostly interesting for an upcoming test relating to the status log template.
2015-05-05 21:45:09 +03:00
@ add,
|
o
templater: introduce word function This function allows returning only the nth "word" from a string. By default a string is split as by Python's split() function default, but an optional third parameter can also override what string the string is split by.
2014-06-13 05:02:23 +04:00
|
o
|
o
o
|\
| o head
| |
o | branch
|/
o user,
|
o person
|
o 1
|
o 1
Test word third parameter used as splitter
$ hg log -Gv -R a --template "{word('0', desc, 'o')}"
tests: add a new commit to test-commandline-template This commit modifies, adds, renames, removes files all at once. It will be mostly interesting for an upcoming test relating to the status log template.
2015-05-05 21:45:09 +03:00
@ M
|
o future
templater: introduce word function This function allows returning only the nth "word" from a string. By default a string is split as by Python's split() function default, but an optional third parameter can also override what string the string is split by.
2014-06-13 05:02:23 +04:00
|
o third
|
o sec
o merge
|\
| o new head
| |
o | new branch
|/
o n
|
o n
|
o
|
o line 1
line 2
Test word error messages for not enough and too many arguments
$ hg log -Gv -R a --template "{word('0')}"
hg: parse error: word expects two or three arguments, got 1
[255]
$ hg log -Gv -R a --template "{word('0', desc, 'o', 'h', 'b', 'o', 'y')}"
hg: parse error: word expects two or three arguments, got 7
[255]
templater: fail more gracefully for blank strings to word
2015-04-30 22:33:36 +03:00
templater: tokenize decimal integer literal (issue4638) (BC) Before this patch, we had to quote integer literals to pass to template functions. It was error-prone, so we should allow "word(0, x)" syntax. Currently only decimal integers are allowed. It's easy to support 0x, 0b and 0 prefixes, but I don't think they are useful. This patch assumes that template keywords and names defined in map files do not start with digits, except for positional variables seen in the schemes extension.
2015-05-01 14:43:55 +03:00
Test word for integer literal
$ hg log -R a --template "{word(2, desc)}\n" -r0
line
templater: fail more gracefully for blank strings to word
2015-04-30 22:33:36 +03:00
Test word for invalid numbers
templater: tokenize decimal integer literal (issue4638) (BC) Before this patch, we had to quote integer literals to pass to template functions. It was error-prone, so we should allow "word(0, x)" syntax. Currently only decimal integers are allowed. It's easy to support 0x, 0b and 0 prefixes, but I don't think they are useful. This patch assumes that template keywords and names defined in map files do not start with digits, except for positional variables seen in the schemes extension.
2015-05-01 14:43:55 +03:00
$ hg log -Gv -R a --template "{word('a', desc)}"
templater: update error message of invalid number passed to word() function "word(3, desc)" is valid now.
2015-05-02 09:49:38 +03:00
hg: parse error: word expects an integer index
templater: fail more gracefully for blank strings to word
2015-04-30 22:33:36 +03:00
[255]
templater: introduce indent function
2015-04-04 11:03:52 +03:00
templater: protect word() from crashing on out of range negative value The function isn't documented to work with negative values at all, but it does, which can be useful. However, the range check didn't account for this.
2015-10-05 19:37:26 +03:00
Test word for out of range
$ hg log -R a --template "{word(10000, desc)}"
$ hg log -R a --template "{word(-10000, desc)}"
templater: introduce indent function
2015-04-04 11:03:52 +03:00
Test indent and not adding to empty lines
$ hg log -T "-----\n{indent(desc, '>> ', ' > ')}\n" -r 0:1 -R a
-----
> line 1
>> line 2
-----
> other 1
>> other 2
>> other 3
Test with non-strings like dates
$ hg log -T "{indent(date, ' ')}\n" -r 2:3 -R a
1200000.00
1300000.00
templater: create string unescape helper (issue4798) This gives us a unified place to do error-handling of string-escaping syntax errors
2015-09-10 00:43:45 +03:00
Test broken string escapes:
$ hg log -T "bogus\\" -R a
hg: parse error: trailing \ in string
[255]
$ hg log -T "\\xy" -R a
hg: parse error: invalid \x escape
[255]
templatefilters: try round-trip utf-8 conversion by json filter (issue4933) As JSON string is known to be a unicode, we should try round-trip conversion for localstr type. This patch tests localstr type explicitly because encoding.fromlocal() may raise Abort for undecodable str, which is probably not what we want. Maybe we can refactor json filter to use encoding module more later. Still "{desc|json}" can't round-trip because showdescription() modifies a localstr object.
2015-11-04 17:48:15 +03:00
templatefilters: make json filter be byte-transparent (BC) (issue4926) This is necessary to preserve filename encoding over JSON. Instead, this patch inserts "|utf8" where non-ascii local-encoding texts can be passed to "|json". See also the commit that introduced "utf8" filter.
2015-12-27 11:59:57 +03:00
json filter should escape HTML tags so that the output can be embedded in hgweb:
$ hg log -T "{'<foo@example.org>'|json}\n" -R a -l1
"\u003cfoo@example.org\u003e"
templater: add parsing and expansion rules to process "templatealias" section The debugtemplate command is updated to show expanded tree, but still the template engine doesn't support alias expansion. That's why the test says "parse error" for now.
2016-03-27 14:31:56 +03:00
Templater supports aliases of symbol and func() styles:
$ hg clone -q a aliases
$ cd aliases
$ cat <<EOF >> .hg/hgrc
> [templatealias]
> r = rev
> rn = "{r}:{node|short}"
> status(c, files) = files % "{c} {file}\n"
> utcdate(d) = localdate(d, "UTC")
> EOF
$ hg debugtemplate -vr0 '{rn} {utcdate(date)|isodate}\n'
(template
('symbol', 'rn')
('string', ' ')
(|
(func
('symbol', 'utcdate')
('symbol', 'date'))
('symbol', 'isodate'))
('string', '\n'))
* expanded:
(template
(template
('symbol', 'rev')
('string', ':')
(|
('symbol', 'node')
('symbol', 'short')))
('string', ' ')
(|
(func
('symbol', 'localdate')
(list
('symbol', 'date')
('string', 'UTC')))
('symbol', 'isodate'))
('string', '\n'))
templater: load and expand aliases by template engine (API) (issue4842) Now template aliases are fully supported in log and formatter templates. As I said before, aliases are not expanded in map files. This avoids possible corruption of our stock styles and web templates. This behavior is undocumented since no map file nor [templates] section are documented at all. Later on, we might want to add [aliases] section to map files if it appears to be useful.
2016-03-27 14:59:36 +03:00
0:1e4e1b8f71e0 1970-01-12 13:46 +0000
templater: add parsing and expansion rules to process "templatealias" section The debugtemplate command is updated to show expanded tree, but still the template engine doesn't support alias expansion. That's why the test says "parse error" for now.
2016-03-27 14:31:56 +03:00
$ hg debugtemplate -vr0 '{status("A", file_adds)}'
(template
(func
('symbol', 'status')
(list
('string', 'A')
('symbol', 'file_adds'))))
* expanded:
(template
(%
('symbol', 'file_adds')
(template
('string', 'A')
('string', ' ')
('symbol', 'file')
('string', '\n'))))
templater: load and expand aliases by template engine (API) (issue4842) Now template aliases are fully supported in log and formatter templates. As I said before, aliases are not expanded in map files. This avoids possible corruption of our stock styles and web templates. This behavior is undocumented since no map file nor [templates] section are documented at all. Later on, we might want to add [aliases] section to map files if it appears to be useful.
2016-03-27 14:59:36 +03:00
A a
templater: add parsing and expansion rules to process "templatealias" section The debugtemplate command is updated to show expanded tree, but still the template engine doesn't support alias expansion. That's why the test says "parse error" for now.
2016-03-27 14:31:56 +03:00
A unary function alias can be called as a filter:
$ hg debugtemplate -vr0 '{date|utcdate|isodate}\n'
(template
(|
(|
('symbol', 'date')
('symbol', 'utcdate'))
('symbol', 'isodate'))
('string', '\n'))
* expanded:
(template
(|
(func
('symbol', 'localdate')
(list
('symbol', 'date')
('string', 'UTC')))
('symbol', 'isodate'))
('string', '\n'))
templater: load and expand aliases by template engine (API) (issue4842) Now template aliases are fully supported in log and formatter templates. As I said before, aliases are not expanded in map files. This avoids possible corruption of our stock styles and web templates. This behavior is undocumented since no map file nor [templates] section are documented at all. Later on, we might want to add [aliases] section to map files if it appears to be useful.
2016-03-27 14:59:36 +03:00
1970-01-12 13:46 +0000
Aliases should be applied only to command arguments and templates in hgrc.
Otherwise, our stock styles and web templates could be corrupted:
$ hg log -r0 -T '{rn} {utcdate(date)|isodate}\n'
0:1e4e1b8f71e0 1970-01-12 13:46 +0000
$ hg log -r0 --config ui.logtemplate='"{rn} {utcdate(date)|isodate}\n"'
0:1e4e1b8f71e0 1970-01-12 13:46 +0000
$ cat <<EOF > tmpl
> changeset = 'nothing expanded:{rn}\n'
> EOF
$ hg log -r0 --style ./tmpl
nothing expanded:
Aliases in formatter:
$ hg branches -T '{pad(branch, 7)} {rn}\n'
default 6:d41e714fe50d
foo 4:bbe44766e73d
templater: add parsing and expansion rules to process "templatealias" section The debugtemplate command is updated to show expanded tree, but still the template engine doesn't support alias expansion. That's why the test says "parse error" for now.
2016-03-27 14:31:56 +03:00
ui: drop template aliases by HGPLAIN Otherwise, scripting output could be suffered from user aliases.
2016-03-27 15:05:55 +03:00
Aliases should honor HGPLAIN:
$ HGPLAIN= hg log -r0 -T 'nothing expanded:{rn}\n'
nothing expanded:
$ HGPLAINEXCEPT=templatealias hg log -r0 -T '{rn}\n'
0:1e4e1b8f71e0
templater: add parsing and expansion rules to process "templatealias" section The debugtemplate command is updated to show expanded tree, but still the template engine doesn't support alias expansion. That's why the test says "parse error" for now.
2016-03-27 14:31:56 +03:00
Unparsable alias:
$ hg debugtemplate --config templatealias.bad='x(' -v '{bad}'
(template
('symbol', 'bad'))
parser: shorten prefix of alias parsing errors These messages seemed to be a bit long. We should try making them fit to 80-col console.
2016-04-17 06:31:06 +03:00
abort: bad definition of template alias "bad": at 2: not a prefix: end
templater: add parsing and expansion rules to process "templatealias" section The debugtemplate command is updated to show expanded tree, but still the template engine doesn't support alias expansion. That's why the test says "parse error" for now.
2016-03-27 14:31:56 +03:00
[255]
templater: load and expand aliases by template engine (API) (issue4842) Now template aliases are fully supported in log and formatter templates. As I said before, aliases are not expanded in map files. This avoids possible corruption of our stock styles and web templates. This behavior is undocumented since no map file nor [templates] section are documented at all. Later on, we might want to add [aliases] section to map files if it appears to be useful.
2016-03-27 14:59:36 +03:00
$ hg log --config templatealias.bad='x(' -T '{bad}'
parser: shorten prefix of alias parsing errors These messages seemed to be a bit long. We should try making them fit to 80-col console.
2016-04-17 06:31:06 +03:00
abort: bad definition of template alias "bad": at 2: not a prefix: end
templater: load and expand aliases by template engine (API) (issue4842) Now template aliases are fully supported in log and formatter templates. As I said before, aliases are not expanded in map files. This avoids possible corruption of our stock styles and web templates. This behavior is undocumented since no map file nor [templates] section are documented at all. Later on, we might want to add [aliases] section to map files if it appears to be useful.
2016-03-27 14:59:36 +03:00
[255]
templater: add parsing and expansion rules to process "templatealias" section The debugtemplate command is updated to show expanded tree, but still the template engine doesn't support alias expansion. That's why the test says "parse error" for now.
2016-03-27 14:31:56 +03:00
$ cd ..
templatefilters: try round-trip utf-8 conversion by json filter (issue4933) As JSON string is known to be a unicode, we should try round-trip conversion for localstr type. This patch tests localstr type explicitly because encoding.fromlocal() may raise Abort for undecodable str, which is probably not what we want. Maybe we can refactor json filter to use encoding module more later. Still "{desc|json}" can't round-trip because showdescription() modifies a localstr object.
2015-11-04 17:48:15 +03:00
Set up repository for non-ascii encoding tests:
$ hg init nonascii
$ cd nonascii
$ python <<EOF
templatefilters: add "utf8" to get utf-8 bytes from local-encoding text This will be applied prior to "|json" filter. This sounds like odd, but it is necessary to handle local-encoding text as well as raw filename bytes. Because filenames are bytes in Mercurial and Unix world, {filename|json} should preserve the original byte sequence, which implies {x|json} -> '"' toutf8b(x) '"' On the other hand, most template strings are in local encoding. Because "|json" filter have to be byte-transparent to filenames, we need something to annotate an input as a local string, that's what "|utf8" will do. {x|utf8|json} -> '"' toutf8b(fromlocal(x)) '"' "|utf8" is an explicit call, so aborts if input bytes can't be converted to UTF-8.
2015-12-27 11:45:05 +03:00
> open('latin1', 'w').write('\xe9')
templatefilters: try round-trip utf-8 conversion by json filter (issue4933) As JSON string is known to be a unicode, we should try round-trip conversion for localstr type. This patch tests localstr type explicitly because encoding.fromlocal() may raise Abort for undecodable str, which is probably not what we want. Maybe we can refactor json filter to use encoding module more later. Still "{desc|json}" can't round-trip because showdescription() modifies a localstr object.
2015-11-04 17:48:15 +03:00
> open('utf-8', 'w').write('\xc3\xa9')
> EOF
$ HGENCODING=utf-8 hg branch -q `cat utf-8`
templatekw: workaround for utf-8 round-trip of {desc} Though our encoding strategy is best effort, {desc} is a primitive keyword that should be worth enough to try hard to preserve UTF-8 bytes.
2015-12-27 14:21:37 +03:00
$ HGENCODING=utf-8 hg ci -qAm "non-ascii branch: `cat utf-8`" utf-8
templatefilters: try round-trip utf-8 conversion by json filter (issue4933) As JSON string is known to be a unicode, we should try round-trip conversion for localstr type. This patch tests localstr type explicitly because encoding.fromlocal() may raise Abort for undecodable str, which is probably not what we want. Maybe we can refactor json filter to use encoding module more later. Still "{desc|json}" can't round-trip because showdescription() modifies a localstr object.
2015-11-04 17:48:15 +03:00
json filter should try round-trip conversion to utf-8:
$ HGENCODING=ascii hg log -T "{branch|json}\n" -r0
"\u00e9"
templatekw: workaround for utf-8 round-trip of {desc} Though our encoding strategy is best effort, {desc} is a primitive keyword that should be worth enough to try hard to preserve UTF-8 bytes.
2015-12-27 14:21:37 +03:00
$ HGENCODING=ascii hg log -T "{desc|json}\n" -r0
"non-ascii branch: \u00e9"
templatefilters: try round-trip utf-8 conversion by json filter (issue4933) As JSON string is known to be a unicode, we should try round-trip conversion for localstr type. This patch tests localstr type explicitly because encoding.fromlocal() may raise Abort for undecodable str, which is probably not what we want. Maybe we can refactor json filter to use encoding module more later. Still "{desc|json}" can't round-trip because showdescription() modifies a localstr object.
2015-11-04 17:48:15 +03:00
templatefilters: make json filter be byte-transparent (BC) (issue4926) This is necessary to preserve filename encoding over JSON. Instead, this patch inserts "|utf8" where non-ascii local-encoding texts can be passed to "|json". See also the commit that introduced "utf8" filter.
2015-12-27 11:59:57 +03:00
json filter takes input as utf-8b:
templatefilters: try round-trip utf-8 conversion by json filter (issue4933) As JSON string is known to be a unicode, we should try round-trip conversion for localstr type. This patch tests localstr type explicitly because encoding.fromlocal() may raise Abort for undecodable str, which is probably not what we want. Maybe we can refactor json filter to use encoding module more later. Still "{desc|json}" can't round-trip because showdescription() modifies a localstr object.
2015-11-04 17:48:15 +03:00
$ HGENCODING=ascii hg log -T "{'`cat utf-8`'|json}\n" -l1
templatefilters: make json filter be byte-transparent (BC) (issue4926) This is necessary to preserve filename encoding over JSON. Instead, this patch inserts "|utf8" where non-ascii local-encoding texts can be passed to "|json". See also the commit that introduced "utf8" filter.
2015-12-27 11:59:57 +03:00
"\u00e9"
$ HGENCODING=ascii hg log -T "{'`cat latin1`'|json}\n" -l1
"\udce9"
templatefilters: try round-trip utf-8 conversion by json filter (issue4933) As JSON string is known to be a unicode, we should try round-trip conversion for localstr type. This patch tests localstr type explicitly because encoding.fromlocal() may raise Abort for undecodable str, which is probably not what we want. Maybe we can refactor json filter to use encoding module more later. Still "{desc|json}" can't round-trip because showdescription() modifies a localstr object.
2015-11-04 17:48:15 +03:00
templatefilters: add "utf8" to get utf-8 bytes from local-encoding text This will be applied prior to "|json" filter. This sounds like odd, but it is necessary to handle local-encoding text as well as raw filename bytes. Because filenames are bytes in Mercurial and Unix world, {filename|json} should preserve the original byte sequence, which implies {x|json} -> '"' toutf8b(x) '"' On the other hand, most template strings are in local encoding. Because "|json" filter have to be byte-transparent to filenames, we need something to annotate an input as a local string, that's what "|utf8" will do. {x|utf8|json} -> '"' toutf8b(fromlocal(x)) '"' "|utf8" is an explicit call, so aborts if input bytes can't be converted to UTF-8.
2015-12-27 11:45:05 +03:00
utf8 filter:
$ HGENCODING=ascii hg log -T "round-trip: {branch|utf8|hex}\n" -r0
round-trip: c3a9
$ HGENCODING=latin1 hg log -T "decoded: {'`cat latin1`'|utf8|hex}\n" -l1
decoded: c3a9
$ HGENCODING=ascii hg log -T "replaced: {'`cat latin1`'|utf8|hex}\n" -l1
abort: decoding near * (glob)
[255]
$ hg log -T "invalid type: {rev|utf8}\n" -r0
abort: template filter 'utf8' is not compatible with keyword 'rev'
[255]
templatefilters: try round-trip utf-8 conversion by json filter (issue4933) As JSON string is known to be a unicode, we should try round-trip conversion for localstr type. This patch tests localstr type explicitly because encoding.fromlocal() may raise Abort for undecodable str, which is probably not what we want. Maybe we can refactor json filter to use encoding module more later. Still "{desc|json}" can't round-trip because showdescription() modifies a localstr object.
2015-11-04 17:48:15 +03:00
$ cd ..
registrar: add templatefunc to mark a function as template function (API) This patch also adds loadfunction() to templater, because this combination helps to figure out how they cooperate with each other. Listing up loadfunction() in dispatch.extraloaders causes implicit loading template function at loading (3rd party) extension. This patch explicitly tests whether templatefunc decorator works as expected, because there is no bundled extension, which defines template function. This change requires that "templatefunc" attribute of (3rd party) extension is registrar.templatefunc or so.
2016-03-29 20:10:44 +03:00
Test that template function in extension is registered as expected
$ cd a
$ cat <<EOF > $TESTTMP/customfunc.py
> from mercurial import registrar
>
> templatefunc = registrar.templatefunc()
>
> @templatefunc('custom()')
> def custom(context, mapping, args):
> return 'custom'
> EOF
$ cat <<EOF > .hg/hgrc
> [extensions]
> customfunc = $TESTTMP/customfunc.py
> EOF
$ hg log -r . -T "{custom()}\n" --config customfunc.enabled=true
custom
$ cd ..
Reference in New Issue Copy Permalink