From: Jeff King <peff@peff.net>
To: Taylor Blau <me@ttaylorr.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH] t/t7700-repack.sh: fix test breakages with `GIT_TEST_MULTI_PACK_INDEX=1`
Date: Tue, 2 Apr 2024 16:24:05 -0400 [thread overview]
Message-ID: <20240402202405.GC875182@coredump.intra.peff.net> (raw)
In-Reply-To: <ZgxSSKGdAicfVhGA@nand.local>
On Tue, Apr 02, 2024 at 02:45:28PM -0400, Taylor Blau wrote:
> I have generally considered the `--write-midx` and
> `GIT_TEST_MULTI_PACK_INDEX` options to be orthogonal to each other. The
> latter is a developer-oriented option that forces Git to write a MIDX
> post-repack regardless of the command-line option.
>
> It predates the `--write-midx` option by a number of years, and IIUC was
> introduced to enhance test coverage while the MIDX was being originally
> developed.
>
> I would argue that GIT_TEST_MULTI_PACK_INDEX should be on the list of
> GIT_TEST_-variables to get rid of as it has served its purpose.
Hmm. Obviously it is of little value in this explicit --write-midx
test, but I thought the main value was just exercising all of the
_other_ tests with a midx in place. Doesn't that potentially have value
(just like testing with SPLIT_INDEX, etc, gets more coverage)?
If it is worth keeping (and I do not really have a strong opinion
there), the real issue seems to me that it does not behave like
--write-midx. That is the source of the problem here, but also makes
test runs with it unrealistic, since the command-line option is how
real-world users would trigger it.
I.e., I would have expected something like this, so that the variables
takes precedence over config but under command-line options:
diff --git a/builtin/repack.c b/builtin/repack.c
index 15e4cccc45..4b02d9cb77 100644
--- a/builtin/repack.c
+++ b/builtin/repack.c
@@ -1197,6 +1197,11 @@ int cmd_repack(int argc, const char **argv, const char *prefix)
git_config(repack_config, &cruft_po_args);
+ write_midx = git_env_bool(GIT_TEST_MULTI_PACK_INDEX, write_midx);
+ if (write_midx)
+ write_bitmaps = git_env_bool(GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP,
+ write_bitmaps);
+
argc = parse_options(argc, argv, prefix, builtin_repack_options,
git_repack_usage, 0);
@@ -1214,10 +1219,6 @@ int cmd_repack(int argc, const char **argv, const char *prefix)
if (!write_midx &&
(!(pack_everything & ALL_INTO_ONE) || !is_bare_repository()))
write_bitmaps = 0;
- } else if (write_bitmaps &&
- git_env_bool(GIT_TEST_MULTI_PACK_INDEX, 0) &&
- git_env_bool(GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP, 0)) {
- write_bitmaps = 0;
}
if (pack_kept_objects < 0)
pack_kept_objects = write_bitmaps > 0 && !write_midx;
@@ -1515,13 +1516,6 @@ int cmd_repack(int argc, const char **argv, const char *prefix)
if (run_update_server_info)
update_server_info(0);
- if (git_env_bool(GIT_TEST_MULTI_PACK_INDEX, 0)) {
- unsigned flags = 0;
- if (git_env_bool(GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP, 0))
- flags |= MIDX_WRITE_BITMAP | MIDX_WRITE_REV_INDEX;
- write_midx_file(get_object_directory(), NULL, NULL, flags);
- }
-
cleanup:
string_list_clear(&names, 1);
existing_packs_release(&existing);
But it gets weird because some tests (like t7700.2) explicitly ask for
bitmaps on the command line and want pack bitmaps but _not_ midx
bitmaps.
So I dunno. Maybe this is a can of worms that is not worth falling into.
After all, these are not "real" environment variables that we expect
users to use. I just wonder if the ci runs with them are buying us
anything for all of the tests outside of t7700.
-Peff
next prev parent reply other threads:[~2024-04-02 20:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-02 16:26 [PATCH] t/t7700-repack.sh: fix test breakages with `GIT_TEST_MULTI_PACK_INDEX=1` Taylor Blau
2024-04-02 18:37 ` Junio C Hamano
2024-04-02 18:45 ` Taylor Blau
2024-04-02 19:55 ` Junio C Hamano
2024-04-02 20:04 ` Taylor Blau
2024-04-02 20:24 ` Jeff King [this message]
2024-04-02 22:10 ` 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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240402202405.GC875182@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=me@ttaylorr.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).