Jeff King <peff@xxxxxxxx> writes: > So I think the whole thing needs to be factored into two phases: a > parsing phase where we build some internal parse tree, and then an > expansion phase where we walk the parse tree for each commit (or ref, or > whatever is being expanded). You are right. I think for-each-ref expander has an attempt for optimization of this exact kind. >> Point is: we're going to keep having more and more format options, >> I think that's a given. At some point, these short mnemonics will just >> stop making sense, and it makes sense to have an escape plan when >> that happens. > > Agreed. And I think it is possible to do it in a backwards-compatible > way; support %(longname:options) for everything, and keep short-hands > like %h and %ad for existing elements without options. Yes, I think %( is not taken in the pretty-format language, so we should be able to do this. I wanted to take your earlier "'%ad' or '%ad(format)'" patch but refrained from doing so. The above line of reasoning is much better for the long term health of the project. -- 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