On Fri, May 22, 2015 at 02:21:16PM -0700, Junio C Hamano wrote: > I ended up doing it as a variant of the latter, "free unless we have > v->buffer pointing at it". Thanks, this version looks good to me minus one micro-nit below. > Sorry for a long delay. No problem. I'm sometimes amazed you find time to write any patches at all. :) > -- >8 -- > Subject: [PATCH] commit-slab: introduce slabname##_peek() function > > There is no API to ask "Does this commit have associated data in > slab?". If an application wants to (1) parse just a few commits at > the beginning of a process, (2) store data for only these commits, > and then (3) start processing many commits, taking into account the > data stored (for a few of them) in the slab, the application would > use slabname##_at() to allocate a space to store data in (2), but > there is no API other than slabname##_at() to use in step (3). This > allocates and wasts new space for these commits the caller is only > interested in checking if they have data stored in step (2). s/wasts/wastes/ -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