git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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


  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).