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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html