On Fri, Jan 10, 2014 at 04:41:20AM -0500, Jeff King wrote:
That being said, we could further optimize this by not opening the files
at all (and make that the responsibility of do_one_ref, which we are
avoiding here). I am slightly worried about the open() cost of my
solution. It's amortized
On 01/14/2014 10:50 AM, Jeff King wrote:
On Fri, Jan 10, 2014 at 04:41:20AM -0500, Jeff King wrote:
That being said, we could further optimize this by not opening the files
at all (and make that the responsibility of do_one_ref, which we are
avoiding here). I am slightly worried about the
On Wed, Jan 08, 2014 at 05:09:25PM +0100, Michael Haggerty wrote:
It's not only racy WRT other processes. If the current git process
would create a new reference, it wouldn't be reflected in the cache.
It's true that the main ref_cache doesn't invalidate itself
automatically either when a
Michael Haggerty mhag...@alum.mit.edu writes:
It's not only racy WRT other processes. If the current git process
would create a new reference, it wouldn't be reflected in the cache.
It's true that the main ref_cache doesn't invalidate itself
automatically either when a new reference is
On 01/08/2014 12:59 AM, Jeff King wrote:
Since 798c35f (get_sha1: warn about full or short object
names that look like refs, 2013-05-29), a 40-hex sha1 causes
us to call dwim_ref on the result, on the off chance that we
have a matching ref. This can cause a noticeable slow-down
when there are
Since 798c35f (get_sha1: warn about full or short object
names that look like refs, 2013-05-29), a 40-hex sha1 causes
us to call dwim_ref on the result, on the off chance that we
have a matching ref. This can cause a noticeable slow-down
when there are a large number of objects. E.g., on
6 matches
Mail list logo
