From: Junio C Hamano <gitster@pobox•com>
To: Jeff King <peff@peff•net>
Cc: "Shawn O. Pearce" <spearce@spearce•org>, git@vger•kernel.org
Subject: Re: [PATCH 0/2] optimizing pack access on "read only" fetch repos
Date: Tue, 29 Jan 2013 14:26:50 -0800 [thread overview]
Message-ID: <7vmwvrocb9.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20130129211932.GA17377@sigill.intra.peff.net> (Jeff King's message of "Tue, 29 Jan 2013 16:19:33 -0500")
Jeff King <peff@peff•net> writes:
>> > But how do these somewhat mediocre concatenated packs get turned into
>> > real packs?
>>
>> How do they get processed in a fetch-only repositories that
>> sometimes run "gc --auto" today? By runninng "repack -a -d -f"
>> occasionally, perhaps?
>
> Do we run "repack -adf" regularly? The usual "git gc" procedure will not
> use "-f", and without that, we will not even consider making deltas
> between objects that were formerly in different packs (but now are in
> the same pack).
Correct. It is not a new problem, and while I think it would need
some solution, the "coalesce 50 small young packs into one" is not
an attempt to address it.
> So you are avoiding doing medium-effort packs ("repack -ad") in favor of
> doing potentially quick packs, but occasionally doing a big-effort pack
> ("repack -adf").
So I think "but occasionally" part is not correct. In either way,
the packs use suboptimal delta, and you have to eventually pack with
"-f", whether you coalesce 50 packs into 1 often or keep paying the
cost of having 50 packs longer.
The trade-off is purely between "one potentially quick coalescing
per fetch in fetch-only repository" vs "any use of the data in the
fetch-only repository (what do they do? build? serving gitweb
locally?) has to deal with 25 packs on average, and we still need to
pay medium repack cost every 50 fetches".
next prev parent reply other threads:[~2013-01-29 22:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-26 22:40 [PATCH 0/2] optimizing pack access on "read only" fetch repos Jeff King
2013-01-26 22:40 ` [PATCH 1/2] fetch: run gc --auto after fetching Jeff King
2013-01-27 1:51 ` Jonathan Nieder
[not found] ` <87bmopzbqx.fsf@gmail.com>
2017-07-12 20:00 ` git gc --auto aquires *.lock files that make a subsequent git-fetch error out Jeff King
2017-07-12 20:30 ` Ævar Arnfjörð Bjarmason
2017-07-12 20:43 ` Jeff King
2013-01-26 22:40 ` [PATCH 2/2] fetch-pack: avoid repeatedly re-scanning pack directory Jeff King
2013-01-27 10:27 ` Jonathan Nieder
2013-01-27 20:09 ` Junio C Hamano
2013-01-27 23:20 ` Jonathan Nieder
2013-01-27 6:32 ` [PATCH 0/2] optimizing pack access on "read only" fetch repos Junio C Hamano
2013-01-29 8:06 ` Shawn Pearce
2013-01-29 8:29 ` Jeff King
2013-01-29 15:25 ` Martin Fick
2013-01-29 15:58 ` Junio C Hamano
2013-01-29 21:19 ` Jeff King
2013-01-29 22:26 ` Junio C Hamano [this message]
2013-01-31 16:47 ` Shawn Pearce
2013-02-01 9:14 ` Jeff King
2013-02-02 10:07 ` Shawn Pearce
2013-01-29 11:01 ` Duy Nguyen
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=7vmwvrocb9.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=peff@peff$(echo .)net \
--cc=spearce@spearce$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox