Junio C Hamano schrieb: > René Scharfe <rene.scharfe@xxxxxxxxxxxxxx> writes: > >> I haven't seen any comments on strbuf_expand. Is it too far out? >> Here it is again, adjusted for current master and with the changes >> to strbuf.[ch] coming first: > > Numbers talk ;-). :-) I just hope someone else has compared the times, too.. > In your previous round, you alluded that the strbuf_expand() > interface could allow caching of the return value of fn(), but I > do not think strbuf_expand() in this patch has anything to > directly support that notion. > > Nor I would expect to --- fn() could keep the really expensive > information cached, keyed with context value, if it wanted to, > but in practice for the purpose of format_commit_item() I do not > offhand see anything cacheable and reusable, unless the user did > stupid things (e.g. use more than one %h in the format string). Yes, that's what I arrived at, too, when I actually wrote and used the function. > I added a few paragraphs to describe the API in the commit log > message, and rewrote "# master" to "(master)" etc. Thanks! I'll send a slightly enhanced version in a two-patch series -- with an actual commit message, including your API desciption -- in just a few seconds. René - 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
