On Thu, Mar 14, 2019 at 09:12:54AM +0000, Eric Wong wrote:
> > The reason it defaults to off is for on-disk compatibility with JGit.
>
> Right. Our documentation seems to indicate JGit just warns (but
> doesn't fall over), so maybe that can be considered separately.
I think it was a hard error in the beginning, but they changed it pretty
soon after we added more flags. So it might be reasonable to just enable
it by default (but it wouldn't hurt to double check the behavior).
I tried running t5310 (which does a back-and-forth with jgit) using this
patch:
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index a154fc29f6..5264bf055a 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -97,7 +97,7 @@ static off_t reuse_packfile_offset;
static int use_bitmap_index_default = 1;
static int use_bitmap_index = -1;
static int write_bitmap_index;
-static uint16_t write_bitmap_options;
+static uint16_t write_bitmap_options = BITMAP_OPT_HASH_CACHE;
static int exclude_promisor_objects;
and it seemed happy.
> As far as serving clones and fetches, public-inbox-init has
> always created bare repos with bitmaps enabled, but without
> the hash-cache for compatibility concerns.
>
> That's a lot of fetches and clones over the years.
The symptom you'd see is that "Compressing objects" during a fetch takes
a long time, and/or produces lousy deltas. But it matters less if:
- you keep things packed pretty promptly, because we don't bother
looking for new deltas between objects in the same pack. Just trying
to clone public-inbox.org/git, it does look like it's mostly packed
(based on the object counts) but the compression phase still takes
10+ seconds.
- how much the names actually help. In your case, I'd think not at
all, because being based on hashes, they're effectively random. So
the pack-objects heuristics to try to find deltas between files of
similar filenames will not help you.
Regarding the second thing, I wondered if the overall packing of your
public-inbox git repo might not be good, so I did a "git repack -adf
--window=1000" on a clone. Hundreds of CPU minutes later, I was only
able to shave off about 80MB. I'm not sure if that means you
occasionally do very aggressive repacks, or if there simply isn't all
that much delta opportunity (after all, you're not storing many versions
of one file, but rather tons of different emails; I would expect to find
deltas between various versions of a patch, though).
Anyway...
> ---------8<-----------
> Subject: [PATCH] repack: enable bitmaps by default on bare repos
>
> A typical use case for bare repos is for serving clones and
> fetches to clients. Enable bitmaps by default on bare repos to
> make it easier for admins to host git repos in a performant way.
>
> Signed-off-by: Eric Wong <e@xxxxxxxxx>
> Helped-by: Jeff King <peff@xxxxxxxx>
This version looks good to me. If we're going to flip the hash-cache
default, I think that should be a separate patch anyway.
-Peff
