On Thu, Nov 23, 2017 at 11:19:42AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > And lazy-load wouldn't help you there for a normal:
> >
> > git log
> >
> > But what's interesting in your command is the pretty-format. Even though
> > decoration is turned on, your format doesn't show a
Jeff King writes:
> And lazy-load wouldn't help you there for a normal:
>
> git log
>
> But what's interesting in your command is the pretty-format. Even though
> decoration is turned on, your format doesn't show any. So we never
> actually ask "is this commit decorated" and the lazy-load helps
On Wed, Nov 22, 2017 at 03:21:06PM -0800, Phil Hord wrote:
> Hm. I think I was confused.
>
> I wrote v1 of this patch a few months ago. Clearly I was wrong about
> rev-parse being afflicted. We have a script that was suffering and it
> uses both "git log --format=%h" and "git rev-parse" to get h
On Wed, Nov 22, 2017 at 1:27 PM, Jeff King wrote:
> On Tue, Nov 21, 2017 at 03:43:36PM -0800, Phil Hord wrote:
>
>> With many thousands of references, a simple `git rev-parse HEAD` may take
>> more than a second to return because it first loads all the refs into
>> memory even though it will never
On Tue, Nov 21, 2017 at 03:43:36PM -0800, Phil Hord wrote:
> With many thousands of references, a simple `git rev-parse HEAD` may take
> more than a second to return because it first loads all the refs into
> memory even though it will never use them.
The overall goal of lazy-loading seems reason
On Tue, Nov 21, 2017, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> I am not sure if "maybe_" is a good name here, though. If anything,
> you are making the semantics of "load_ref_decorations()" to "maybe"
> (but I do not suggest renaming that one).
>
> How about calling it to load_ref_deco
Junio C Hamano writes:
> Other than that, I like what this patch attempts to do. A nicely
> identified low-hanging fruit ;-).
Having said that, this will have a bad interaction with another
topic in flight: <20171121213341.13939-1-rafa.al...@gmail.com>
Perhaps this should wait until the other
Phil Hord writes:
> With many thousands of references, a simple `git rev-parse HEAD` may take
> more than a second to return because it first loads all the refs into
> memory even though it will never use them.
>
> Defer loading any references until we actually need them.
>
> Signed-off-by: Phil
With many thousands of references, a simple `git rev-parse HEAD` may take
more than a second to return because it first loads all the refs into
memory even though it will never use them.
Defer loading any references until we actually need them.
Signed-off-by: Phil Hord
---
log-tree.c | 9 ++
9 matches
Mail list logo