From: Derrick Stolee <derrickstolee@github.com>
To: Kyle Zhao via GitGitGadget <gitgitgadget@gmail.com>, git@vger.kernel.org
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Kyle Zhao" <kylezhao@tencent.com>
Subject: Re: [PATCH] send-pack.c: add config push.useBitmaps
Date: Wed, 15 Jun 2022 09:09:35 -0400 [thread overview]
Message-ID: <57a7393d-add0-468a-a276-5241c2c84065@github.com> (raw)
In-Reply-To: <pull.1263.git.1655291320433.gitgitgadget@gmail.com>
On 6/15/22 7:08 AM, Kyle Zhao via GitGitGadget wrote:
> From: Kyle Zhao <kylezhao@tencent.com>
>
> This allows you to disabled bitmaps for "git push". Default is false.
s/disabled/disable/
> Bitmaps are designed to speed up the "counting objects" phase of
> subsequent packs created for clones and fetches.
> But in some cases, turning bitmaps on does horrible things for "push"
> performance[1].
I would rephrase this message body as follows:
Reachability bitmaps are designed to speed up the "counting objects"
phase of generating a pack during a clone or fetch. They are not
optimized for Git clients sending a small topic branch via "git push".
In some cases (see [1]), using reachability bitmaps during "git push"
can cause significant performance regressions.
Add a new "push.useBitmaps" config option to disable reachability
bitmaps during "git push". This allows reachability bitmaps to still
be used in other areas, such as "git rev-list --use-bitmap-index".
> [1]: https://lore.kernel.org/git/87zhoz8b9o.fsf@evledraar.gmail.com/
> +
> +push.useBitmaps::
> + If this config and `pack.useBitmaps` are both "true", git will
> + use pack bitmaps (if available) when git push. Default is false.
Rewording slightly:
If this config and `pack.useBitmaps` are both `true`, then Git will
use reachability bitmaps during `git push`, if available (disabled
by default).
> \ No newline at end of file
Please fix this missing newline.
I'm glad that this references `pack.useBitmaps`. I wonder if that
config is sufficient for your purposes: do you expect to use your
bitmaps to generate pack-files in any other way than "git push"?
That is: are you serving remote requests from your repo with your
bitmaps while also using "git push"? Or, are you using bitmaps
only for things like "git rev-list --use-bitmap-index"?
I just want to compare this with `pack.useSparse` which targets
"git push", but focuses entirely on the pack-creation part of the
operation. Since the existence of reachability bitmaps overrides
the sparse algorithm, this does not affect Git servers (who should
have a reachability bitmap).
I just want to be sure that using pack.useBitmaps=false would not
be sufficient for your situation (and probably most situations).
> diff --git a/send-pack.c b/send-pack.c
> index bc0fcdbb000..d6091571caa 100644
> --- a/send-pack.c
> +++ b/send-pack.c
> @@ -84,6 +84,8 @@ static int pack_objects(int fd, struct ref *refs, struct oid_array *advertised,
> strvec_push(&po.args, "--progress");
> if (is_repository_shallow(the_repository))
> strvec_push(&po.args, "--shallow");
> + if (!args->use_bitmaps)
> + strvec_push(&po.args, "--no-use-bitmap-index");
Here is where you specify the lower-level pack creation only
when sending a pack. It is very focused. Good.
> + int use_bitmaps = 0;
> + git_config_get_bool("push.usebitmaps", &use_bitmaps);
> + if (use_bitmaps)
> + args->use_bitmaps = 1;
You can instead write this as:
if (!git_config_get_bool("push.usebitmaps", &use_bitmaps))
args->use_bitmaps = use_bitmaps;
> diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
> index dedca106a7a..ee0b912a5e8 100755
> --- a/t/t5516-fetch-push.sh
> +++ b/t/t5516-fetch-push.sh
> @@ -1865,4 +1865,15 @@ test_expect_success 'push warns or fails when using username:password' '
> test_line_count = 1 warnings
> '
>
> +test_expect_success 'push with config push.useBitmaps' '
> + mk_test testrepo heads/main &&
> + git checkout main &&
> + GIT_TRACE=1 git push testrepo main:test >/dev/null 2>stderr &&
Just use "err" instead of "stderr".
> + grep "no-use-bitmap-index" stderr &&
> +
> + git config push.useBitmaps true &&
> + GIT_TRACE=1 git push testrepo main:test2 >/dev/null 2>stderr &&
> + ! grep "no-use-bitmap-index" stderr
> +'
I believe this test is correct, but it might be worth looking
into test_subcommand if you can determine the exact subcommand
arguments you are looking for.
Thanks,
-Stolee
next prev parent reply other threads:[~2022-06-15 13:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-15 11:08 [PATCH] send-pack.c: add config push.useBitmaps Kyle Zhao via GitGitGadget
2022-06-15 13:09 ` Derrick Stolee [this message]
2022-06-15 21:24 ` Taylor Blau
2022-06-15 19:47 ` Ævar Arnfjörð Bjarmason
2022-06-15 21:32 ` Taylor Blau
2022-06-16 2:13 ` [Internet]Re: " kylezhao(赵柯宇)
2022-06-16 3:36 ` [PATCH v2] " Kyle Zhao via GitGitGadget
2022-06-16 13:02 ` Derrick Stolee
2022-06-16 13:38 ` Ævar Arnfjörð Bjarmason
2022-06-16 15:11 ` [Internet]Re: " kylezhao(赵柯宇)
2022-06-16 21:17 ` Taylor Blau
2022-06-16 18:12 ` Junio C Hamano
2022-06-16 21:04 ` Jeff King
2022-06-17 3:59 ` [PATCH v3] " Kyle Zhao via GitGitGadget
2022-06-17 17:01 ` Junio C Hamano
2022-06-17 19:06 ` [PATCH v4] " Kyle Zhao via GitGitGadget
2022-06-17 21:32 ` 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=57a7393d-add0-468a-a276-5241c2c84065@github.com \
--to=derrickstolee@github.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=kylezhao@tencent.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).