Jeff King writes:
>> Thanks for spotting it. I wonder if it was broken like this forever
>> since the beginning X-<.
>
> Not quite since the beginning; it comes from 8d2dfc49b1
> (process_{tree,blob}: show objects without buffering, 2009-04-10). I
> suspect nobody noticed because the cost for th
On Thu, Sep 12, 2019 at 09:52:53AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> >> I was surprised we ever called repo_get_commit_tree() at all, since
> >> we're literally just traversing commits here. It looks like
> >> list-objects.c is very happy to queue pending trees for each commit
Jeff King writes:
>> I was surprised we ever called repo_get_commit_tree() at all, since
>> we're literally just traversing commits here. It looks like
>> list-objects.c is very happy to queue pending trees for each commit,
>> even if we're just going to throw them away when we get to
>> process_
On 9/11/2019 9:11 PM, Jeff King wrote:
> On Wed, Sep 11, 2019 at 08:18:46PM -0400, Jeff King wrote:
>
>>> That creates an interesting problem for commits that have _already_ been
>>> parsed using the commit graph. Their commit->object.parsed flag is set,
>>> their commit->graph_pos is set, but the
On Wed, Sep 11, 2019 at 09:11:37PM -0400, Jeff King wrote:
> Let's try it after running "git commit-graph write":
>
> [before]
> Benchmark #1: git -C linux rev-list HEAD >/dev/null
> Time (mean ± σ): 1.458 s ± 0.011 s[User: 1.199 s, System: 0.259
> s]
> Range (min … max):
On Wed, Sep 11, 2019 at 08:18:46PM -0400, Jeff King wrote:
> > That creates an interesting problem for commits that have _already_ been
> > parsed using the commit graph. Their commit->object.parsed flag is set,
> > their commit->graph_pos is set, but their commit->maybe_tree may still
> > be NULL
6 matches
Mail list logo
