Jeff King 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 up at
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 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 parent/timestamp/tre
On Fri, Jan 25, 2013 at 07:36:18AM -0800, Junio C Hamano wrote:
> Jonathon Mah 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); {
> >
4 matches
Mail list logo
