Re: Fwd: [PATCH 2/2] pretty.c: allow date formats in user format strings
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 9, 2011, 21:06 UTC
- Message-ID
- <7v39mw9f7a.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20110307161758.GB11934@sigill.intra.peff.net>
Jeff King <peff@peff.net> 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.
Show 8 quoted lines
>> 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.