From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Michael Haggerty <mhagger@alum.mit.edu>
Subject: Re: [PATCH v5] pack-objects mru
Date: Thu, 11 Aug 2016 08:11:33 -0700 [thread overview]
Message-ID: <xmqqmvkj2vdm.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20160811095710.p2bffympjlwmv3gc@sigill.intra.peff.net> (Jeff King's message of "Thu, 11 Aug 2016 05:57:10 -0400")
Jeff King <peff@peff.net> writes:
> So considering "--depth" as a space-saving measure for --aggressive does
> not seem that effective. But it feels weird to quietly drop actions
> people might have done with previous aggressive runs.
That argument cuts both ways, doesn't it?
If the user explicitly asks to use lower "--depth" from the command
line when the second repack runs, the intention is clear: the
existing pack may use delta chains that are too long and is
detrimental to the run-time performance, and the user wants to
correct it by repacking with shorter delta chain.
Should the act of letting "gc --auto" use lower "--depth", by not
configuring to always use deeper chain, be interpreted the same way?
I am not sure. The old packing with large --depth is something the
user did long time ago, and the decision the user made not to use
large depth always is also something the user did long time ago. I
do not think it is so cut-and-dried which one of the two conflicting
wishes we should honor when running the second repack, especially
when it is run unattended like "gc --auto" does.
next prev parent reply other threads:[~2016-08-11 15:11 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-29 4:04 [PATCH v2 0/7] speed up pack-objects counting with many packs Jeff King
2016-07-29 4:06 ` [PATCH v2 1/7] t/perf: add tests for many-pack scenarios Jeff King
2016-07-29 4:06 ` [PATCH v2 2/7] sha1_file: drop free_pack_by_name Jeff King
2016-07-29 4:06 ` [PATCH v2 3/7] add generic most-recently-used list Jeff King
2016-07-29 4:09 ` [PATCH v2 4/7] find_pack_entry: replace last_found_pack with MRU cache Jeff King
2016-07-29 4:10 ` [PATCH v2 5/7] pack-objects: break out of want_object loop early Jeff King
2016-07-29 4:11 ` [PATCH v2 6/7] pack-objects: compute local/ignore_pack_keep early Jeff King
2016-07-29 4:15 ` [PATCH v2 7/7] pack-objects: use mru list when iterating over packs Jeff King
2016-07-29 5:45 ` Jeff King
2016-07-29 15:02 ` Junio C Hamano
2016-08-08 14:50 ` Jeff King
2016-08-08 16:28 ` Junio C Hamano
2016-08-08 16:51 ` Jeff King
2016-08-08 17:16 ` Junio C Hamano
2016-08-09 14:04 ` Jeff King
2016-08-09 17:45 ` Jeff King
2016-08-09 18:06 ` Junio C Hamano
2016-08-09 22:29 ` Junio C Hamano
2016-08-10 11:52 ` [PATCH v3 0/2] pack-objects mru Jeff King
2016-08-10 12:02 ` [PATCH v3 1/2] pack-objects: break delta cycles before delta-search phase Jeff King
2016-08-10 20:17 ` Junio C Hamano
2016-08-11 5:02 ` Jeff King
2016-08-11 5:15 ` [PATCH v4 " Jeff King
2016-08-11 6:57 ` [PATCH v3 " Jeff King
2016-08-11 9:20 ` [PATCH v5] pack-objects mru Jeff King
2016-08-11 9:24 ` [PATCH v5 1/4] provide an initializer for "struct object_info" Jeff King
2016-08-11 9:25 ` [PATCH v5 2/4] sha1_file: make packed_object_info public Jeff King
2016-08-11 9:26 ` [PATCH v5 3/4] pack-objects: break delta cycles before delta-search phase Jeff King
2016-08-11 9:26 ` [PATCH v5 4/4] pack-objects: use mru list when iterating over packs Jeff King
2016-08-11 9:57 ` [PATCH v5] pack-objects mru Jeff King
2016-08-11 15:11 ` Junio C Hamano [this message]
2016-08-11 16:19 ` Jeff King
2016-08-10 12:03 ` [PATCH v3 2/2] pack-objects: use mru list when iterating over packs Jeff King
2016-08-10 16:47 ` [PATCH v3 0/2] pack-objects mru Junio C Hamano
2016-08-11 4:48 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqmvkj2vdm.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=mhagger@alum.mit.edu \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.