From: Christian Couder <christian.couder@gmail.com>
To: Jeff King <peff@peff.net>
Cc: git <git@vger.kernel.org>, Junio C Hamano <gitster@pobox.com>,
Christian Couder <chriscool@tuxfamily.org>,
Ramsay Jones <ramsay@ramsayjones.plus.com>,
Jonathan Tan <jonathantanmy@google.com>
Subject: Re: [PATCH v3 7/9] pack-objects: introduce pack.allowPackReuse
Date: Fri, 13 Dec 2019 14:27:26 +0100 [thread overview]
Message-ID: <CAP8UFD3H_6E9FWprV_bHUwwQK96JD1jFtvMBecM5ajnbSjjxPQ@mail.gmail.com> (raw)
In-Reply-To: <20191209071412.GG40570@coredump.intra.peff.net>
On Mon, Dec 9, 2019 at 8:14 AM Jeff King <peff@peff.net> wrote:
>
> On Fri, Nov 15, 2019 at 03:15:39PM +0100, Christian Couder wrote:
>
> > From: Jeff King <peff@peff.net>
> >
> > Let's make it possible to configure if we want pack reuse or not.
>
> ...because? :)
>
> I mostly used it for debugging and performance testing. I don't think
> there should be any big downside to using it that would cause people to
> want to turn it off. But it _might_ cause larger packs, because we
> wouldn't consider the reused objects as bases for finding new deltas.
Ok, I changed the commit message to:
Let's make it possible to configure if we want pack reuse or not.
The main reason it might not be wanted is probably debugging and
performance testing, though pack reuse _might_ cause larger packs,
because we wouldn't consider the reused objects as bases for
finding new deltas.
> I think the documentation could mention this. And maybe make it a bit
> more clear what "reuse" means.
>
> So maybe:
>
> diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt
> index 58323a351f..0dac580581 100644
> --- a/Documentation/config/pack.txt
> +++ b/Documentation/config/pack.txt
> @@ -28,8 +28,11 @@ all existing objects. You can force recompression by passing the -F option
> to linkgit:git-repack[1].
>
> pack.allowPackReuse::
> - When true, which is the default, Git will try to reuse parts
> - of existing packfiles when preparing new packfiles.
> + When true, and when reachability bitmaps are enabled,
> + pack-objects will try to send parts of the bitmapped packfile
> + verbatim. This can reduce memory and CPU usage to serve fetches,
> + but might result in sending a slightly larger pack. Defaults to
> + true.
Yeah, great! I use the above in my current version. Thanks!
next prev parent reply other threads:[~2019-12-13 20:37 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-15 14:15 [PATCH v3 0/9] Rewrite packfile reuse code Christian Couder
2019-11-15 14:15 ` [PATCH v3 1/9] builtin/pack-objects: report reused packfile objects Christian Couder
2019-12-09 6:24 ` Jeff King
2019-12-11 13:48 ` Christian Couder
2019-11-15 14:15 ` [PATCH v3 2/9] packfile: expose get_delta_base() Christian Couder
2019-12-09 6:26 ` Jeff King
2019-11-15 14:15 ` [PATCH v3 3/9] ewah/bitmap: introduce bitmap_word_alloc() Christian Couder
2019-12-09 6:28 ` Jeff King
2019-12-11 13:50 ` Christian Couder
2019-12-12 5:45 ` Jeff King
2019-11-15 14:15 ` [PATCH v3 4/9] pack-bitmap: don't rely on bitmap_git->reuse_objects Christian Couder
2019-12-09 6:47 ` Jeff King
2019-12-13 13:26 ` Christian Couder
2019-11-15 14:15 ` [PATCH v3 5/9] pack-bitmap: introduce bitmap_walk_contains() Christian Couder
2019-12-09 7:06 ` Jeff King
2019-12-13 13:27 ` Christian Couder
2019-11-15 14:15 ` [PATCH v3 6/9] csum-file: introduce hashfile_total() Christian Couder
2019-12-09 7:07 ` Jeff King
2019-11-15 14:15 ` [PATCH v3 7/9] pack-objects: introduce pack.allowPackReuse Christian Couder
2019-12-09 7:14 ` Jeff King
2019-12-13 13:27 ` Christian Couder [this message]
2019-11-15 14:15 ` [PATCH v3 8/9] builtin/pack-objects: introduce obj_is_packed() Christian Couder
2019-12-09 7:14 ` Jeff King
2019-11-15 14:15 ` [PATCH v3 9/9] pack-objects: improve partial packfile reuse Christian Couder
2019-12-09 8:11 ` Jeff King
2019-12-18 11:26 ` Christian Couder
2019-12-19 0:42 ` Jeff King
2020-01-23 22:29 ` Christian Couder
2019-11-15 18:03 ` [PATCH v3 0/9] Rewrite packfile reuse code Jonathan Tan
2019-11-25 6:30 ` Junio C Hamano
2019-11-25 6:36 ` Junio C Hamano
2019-12-06 21:42 ` Junio C Hamano
2019-12-07 10:12 ` Christian Couder
2019-12-07 20:47 ` Johannes Schindelin
2019-12-08 7:53 ` Christian Couder
2019-12-08 8:54 ` Johannes Schindelin
2019-12-08 10:26 ` Christian Couder
2019-12-08 10:45 ` Johannes Schindelin
2019-12-09 6:18 ` Jeff King
2019-12-09 9:28 ` Johannes Schindelin
2019-12-09 19:00 ` Junio C Hamano
2019-12-09 19:05 ` Junio C Hamano
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=CAP8UFD3H_6E9FWprV_bHUwwQK96JD1jFtvMBecM5ajnbSjjxPQ@mail.gmail.com \
--to=christian.couder@gmail.com \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jonathantanmy@google.com \
--cc=peff@peff.net \
--cc=ramsay@ramsayjones.plus.com \
/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.