From: Taylor Blau <me@ttaylorr.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Taylor Blau <me@ttaylorr.com>, git@vger.kernel.org, peff@peff.net
Subject: Re: [PATCH 3/4] midx.c: respect 'pack.writeBitmapHashcache' when writing bitmaps
Date: Thu, 9 Sep 2021 10:47:00 -0400 [thread overview]
Message-ID: <YToeZIIrFH42BRe7@nand.local> (raw)
In-Reply-To: <87zgsmdu6d.fsf@evledraar.gmail.com>
On Thu, Sep 09, 2021 at 10:18:10AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Tue, Sep 07 2021, Taylor Blau wrote:
>
> > On Wed, Sep 08, 2021 at 03:40:19AM +0200, Ævar Arnfjörð Bjarmason wrote:
> >>
> >> On Tue, Sep 07 2021, Taylor Blau wrote:
> >>
> >> > +static int git_multi_pack_index_write_config(const char *var, const char *value,
> >> > + void *cb)
> >> > +{
> >> > + if (!strcmp(var, "pack.writebitmaphashcache")) {
> >> > + if (git_config_bool(var, value))
> >> > + opts.flags |= MIDX_WRITE_BITMAP_HASH_CACHE;
> >> > + else
> >> > + opts.flags &= ~MIDX_WRITE_BITMAP_HASH_CACHE;
> >> > + }
> >> > +
> >> > + /*
> >> > + * No need to fall-back to 'git_default_config', since this was already
> >> > + * called in 'cmd_multi_pack_index()'.
> >> > + */
> >> > + return 0;
> >> > +}
> >> > +
> >> > static int cmd_multi_pack_index_write(int argc, const char **argv)
> >> > {
> >> > struct option *options;
> >> > @@ -73,6 +90,10 @@ static int cmd_multi_pack_index_write(int argc, const char **argv)
> >> > OPT_END(),
> >> > };
> >> >
> >> > + opts.flags |= MIDX_WRITE_BITMAP_HASH_CACHE;
> >> > +
> >> > + git_config(git_multi_pack_index_write_config, NULL);
> >> > +
> >>
> >> Since this is a write-only config option it would seem more logical to
> >> just call git_config() once, and have a git_multip_pack_index_config,
> >> which then would fall back on git_default_config, so we iterate it once,
> >> and no need for a comment about the oddity.
> >
> > Perhaps, but I'm not crazy about each sub-command having to call
> > git_config() itself when 'write' is the only one that actually has any
> > values to read.
> >
> > FWIW, the commit-graph builtin does the same thing as is written here
> > (calling git_config() twice, once in cmd_commit_graph() with
> > git_default_config as the callback and again in cmd_commit_graph_write()
> > with git_commit_graph_write_config as the callback).
>
> I didn't notice your earlier d356d5debe5 (commit-graph: introduce
> 'commitGraph.maxNewFilters', 2020-09-17). As an aside the test added in
> that commit seems to be broken or not testing that code change at all,
> if I comment out the git_config(git_commit_graph_write_config, &opts)
> it'll pass.
That makes sense; the test that d356d5debe5 added is ensuring that the
option `--max-new-filters` overrides any configured value of
`commitGraph.maxNewFilters` (so not reading the configuration would be
fine there).
> More importantly, the same issue with the commit-graph test seems to be
> the case here, if I comment out the added config reading code it'll
> still pass, it seems to be testing something, but not that the config is
> being read.
I think this also makes sense; since MIDX_WRITE_BITMAP_HASH_CACHE is the
default and is set in cmd_multi_pack_index_write(). So it may be worth
adding a test to say "make sure the hash-cache _isn't_ written when I:
git config pack.writeBitmapHashCache &&
git multi-pack-index write --bitmap
But I don't feel strongly about it (hence I didn't write such a test in
the original version which I sent here). If you think it would be
helpful in a newer version, I'm happy to add it.
Thanks,
Taylor
next prev parent reply other threads:[~2021-09-09 14:49 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-07 21:17 [PATCH 0/4] pack-bitmap: permute existing namehash values Taylor Blau
2021-09-07 21:17 ` [PATCH 1/4] t/helper/test-bitmap.c: add 'dump-hashes' mode Taylor Blau
2021-09-08 1:37 ` Ævar Arnfjörð Bjarmason
2021-09-08 2:24 ` Taylor Blau
2021-09-07 21:17 ` [PATCH 2/4] pack-bitmap.c: propagate namehash values from existing bitmaps Taylor Blau
2021-09-07 21:18 ` [PATCH 3/4] midx.c: respect 'pack.writeBitmapHashcache' when writing bitmaps Taylor Blau
2021-09-08 1:40 ` Ævar Arnfjörð Bjarmason
2021-09-08 2:28 ` Taylor Blau
2021-09-09 8:18 ` Ævar Arnfjörð Bjarmason
2021-09-09 9:34 ` Ævar Arnfjörð Bjarmason
2021-09-09 14:55 ` Taylor Blau
2021-09-09 15:50 ` Ævar Arnfjörð Bjarmason
2021-09-09 16:23 ` Taylor Blau
2021-09-09 14:47 ` Taylor Blau [this message]
2021-09-13 0:38 ` Junio C Hamano
2021-09-14 1:15 ` Taylor Blau
2021-09-07 21:18 ` [PATCH 4/4] t5326: test propagating hashcache values Taylor Blau
2021-09-08 1:46 ` Ævar Arnfjörð Bjarmason
2021-09-08 2:30 ` Taylor Blau
2021-09-17 8:56 ` Ævar Arnfjörð Bjarmason
2021-09-17 17:32 ` Taylor Blau
2021-09-17 19:22 ` Ævar Arnfjörð Bjarmason
2021-09-13 0:46 ` Junio C Hamano
2021-09-14 1:12 ` Taylor Blau
2021-09-14 2:05 ` Junio C Hamano
2021-09-14 5:11 ` Taylor Blau
2021-09-14 5:17 ` Taylor Blau
2021-09-14 5:27 ` Jeff King
2021-09-14 5:31 ` Taylor Blau
2021-09-14 5:23 ` Jeff King
2021-09-14 5:49 ` Junio C Hamano
2021-09-14 22:05 ` [PATCH v2 0/7] pack-bitmap: permute existing namehash values Taylor Blau
2021-09-14 22:06 ` [PATCH v2 1/7] t/helper/test-bitmap.c: add 'dump-hashes' mode Taylor Blau
2021-09-14 22:06 ` [PATCH v2 2/7] pack-bitmap.c: propagate namehash values from existing bitmaps Taylor Blau
2021-09-14 22:06 ` [PATCH v2 3/7] midx.c: respect 'pack.writeBitmapHashcache' when writing bitmaps Taylor Blau
2021-09-14 22:06 ` [PATCH v2 4/7] p5326: create missing 'perf-tag' tag Taylor Blau
2021-09-16 22:36 ` Jeff King
2021-09-17 4:14 ` Taylor Blau
2021-09-14 22:06 ` [PATCH v2 5/7] p5326: don't set core.multiPackIndex unnecessarily Taylor Blau
2021-09-16 22:38 ` Jeff King
2021-09-14 22:06 ` [PATCH v2 6/7] p5326: generate pack bitmaps before writing the MIDX bitmap Taylor Blau
2021-09-16 22:45 ` Jeff King
2021-09-17 4:20 ` Taylor Blau
2021-09-14 22:06 ` [PATCH v2 7/7] t5326: test propagating hashcache values Taylor Blau
2021-09-16 22:49 ` Jeff King
2021-09-16 22:52 ` [PATCH v2 0/7] pack-bitmap: permute existing namehash values Jeff King
2021-09-17 21:21 ` [PATCH v3 " Taylor Blau
2021-09-17 21:21 ` [PATCH v3 1/7] t/helper/test-bitmap.c: add 'dump-hashes' mode Taylor Blau
2021-09-17 21:21 ` [PATCH v3 2/7] pack-bitmap.c: propagate namehash values from existing bitmaps Taylor Blau
2021-09-17 21:21 ` [PATCH v3 3/7] midx.c: respect 'pack.writeBitmapHashcache' when writing bitmaps Taylor Blau
2021-09-17 21:21 ` [PATCH v3 4/7] p5326: create missing 'perf-tag' tag Taylor Blau
2021-09-17 21:21 ` [PATCH v3 5/7] p5326: don't set core.multiPackIndex unnecessarily Taylor Blau
2021-09-17 21:21 ` [PATCH v3 6/7] p5326: generate pack bitmaps before writing the MIDX bitmap Taylor Blau
2021-09-17 21:21 ` [PATCH v3 7/7] t5326: test propagating hashcache values Taylor Blau
2021-09-17 22:12 ` [PATCH v3 0/7] pack-bitmap: permute existing namehash values 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=YToeZIIrFH42BRe7@nand.local \
--to=me@ttaylorr.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--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.