On Fri, Jan 25, 2013 at 07:36:18AM -0800, Junio C Hamano wrote:
Jonathon Mah j...@me.com writes:
Just to note, the proposals so far don't prevent a smart-ass
function from freeing the buffer when it's called underneath the
use/release scope, as in:
with_commit_buffer(commit); {
Jeff King p...@peff.net writes:
Yeah, agreed. I started to fix this up with a use/unuse pattern and
realized something: all of the call sites are calling logmsg_reencode
anyway, because that is the next logical step in doing anything with the
buffer that is not just parsing out the
On Sat, Jan 26, 2013 at 01:26:53PM -0800, Junio C Hamano wrote:
This looks very good.
I wonder if this lets us get rid of the hack in cmd_log_walk() that
does this:
while ((commit = get_revision(rev)) != NULL) {
if (!log_tree_commit(rev, commit)
Jeff King p...@peff.net writes:
My HEAD has about 400/3000 non-unique commits, which matches your
numbers percentage-wise. Dropping the lines above (and always freeing)
takes my best-of-five for git log -g from 0.085s to 0.080s. Which is
well within the noise. Doing git log -g Makefile ended
4 matches
Mail list logo
