Easy to reproduce: [keywordmaps] Author = {foo|utcdate} You'll get a backtrace from which to conclude that 'foo' is not a valid keyword, once you realize that text[0] refers to 'foo'. It's less subtle when you misspelled "date" as "data".
--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:29 EDT --- This bug was previously known as _bug_ 3343 at http://mercurial.selenic.com/bts/issue3343 Bug Status was UNCONFIRMED but everconfirmed was true Setting status to CONFIRMED
Test reproducing the issue: $ cat <<EOF >> $HGRCPATH > [extensions] > keyword = > [ui] > interactive = true > EOF $ hg init $ hg --quiet kwdemo "Branch = {foo|utcdate}" I move it to the keyword component, but this is likely a pure templating issue.
Well, you also get a traceback with hg log --template '{foo|utcdate}\n' So I'd say it's not keyword specific. That's partly the reason why I kept the clumsy kwdemo command in the extension: Provide an ad hoc test for templating so you don't mess up your files. Not sure how I could test the validity of templates during normal background operation of the extension without a big slowdown.
Well, if the log call had tracebacked I would not have moved the bug to keyword category, but here: $ hg log --template '{foo|utcdate}\n' -l1 hg: parse error: unknown function 'utcdate' So maybe there is a try/except in the log code or something else, I do not know.
You are absolutely right of course, sorry. You get a traceback when having keyword enabled with hg log --template '{foo|utcdate}\n' because utcdate is one of the additional filters provided by the extension, but the extension does not catch errors with the additional filters. Will look into it.
To be more precise, with either utcdate or svnutcdate because do: return util.datestr((text[0], 0), '<format>') Something like hg log --template '{foo|shortdate}\n' returns the current date instead of a traceback - not exactly meaningful, but no traceback because the text argument is not split up. Looks like I should do the following for utcdate and svnutcdate: try: return util.datestr((text[0], 0), '<format>') except IndexError: return util.datestr(text, '<format>')
You are right, my example was invalid. Here is a recipe for log: hg log --template '{foo|localdate}\n' -l1 Reassigning to mercurial itself, updating title. And yes, some date filters do interesting things with bogus arguments.
(In reply to comment #7) imho keyword should still be in charge of avoiding a traceback (will send a patch shortly), but hg log --template '{foo|localdate}\n' should probably abort with something like: parse error: invalid date Hm, how to detect bogus dates ...
(In reply to comment #7) I meant to say that hg log --template '{foo|shortdate}\n' does not give a traceback, but also not a meaningful value. So I'll wait with a patch until I see how tracebacks because of failed "date splitting" are handled in the core.
Fixed by http://selenic.com/repo/hg/rev/bededd3f0735 Christian Ebert <blacktrash@gmx.net> templatefilters: avoid traceback caused by bogus date input (issue3344) Wrap datefilters which split date texts with util.parsedate. We do not abort, as the bogus date must have been given by the user. (please test the fix)