On Thu, Aug 28, 2008 at 04:36:51PM -0700, Junio C Hamano wrote:
I was actually thinking about rejecting this, asking for something that
allows to express all the other %[ai][dDri] format can express, and
perhaps more. So I think "%ad(short)" is a good direction to go, except
that 'd' is already taken. Perhaps %a(date), %a(shortdate,local),...?
I was thinking we could accept %ad _or_ %ad(short), but of course
introducing the latter can break existing "%ad(my other random text)"
which is a bad idea.
I really think some consideration should be given to introducing
arbitrary "arguments" to formatting specifiers, of which this is one
example. Another that has been mentioned is pulling an arbitrary element
from a list.
How do you feel about a brand new syntax (and supporting the old, of
course) that is syntactically a little easier to extend. Like:
%(macro, key=val, key=val)
e.g.
%(authordate, format=short, tz=local)
where the syntax can be easily parsed without understanding what
"authordate" means. Jakub already suggested something akin to RPM's
macro expansion, though I haven't looked too closely at it.
Oh, and before anybody asks, even if we do %a(specifier), you can keep
writing "%ad" if you are used to it. I am not talking about deprecating
the existing ones, but making future extensions easier without forcing
people to remember cryptic one-letter format specifiers.
Yes, I don't see a need to get rid of the existing ones. Introducing a
new syntax does have the possibility of breaking existing scripts, since
we just leave unrecognized expansions in place (in fact, just adding %as
has the potential to break scripts!).
Worst case, we can introduce a --pretty=otherformat:, but I don't know
if people are really expecting "%a(blah)" to be left untouched
currently. I don't think we ever claimed that % was magical.
-Peff