When writing a new multi-pack index, write_midx_internal() attempts to
load any existing one to fill in some pieces of information. But it uses
load_multi_pack_index(), which ignores the configuration
"core.multiPackIndex", which indicates whether or not Git is allowed to
read an existing multi-pack-index.
Replace this with a routine that does respect that setting, to avoid
reading multi-pack-index files when told not to.
This avoids a problem that would arise in subsequent patches due to the
combination of 'git repack' reopening the object store in-process and
the multi-pack index code not checking whether a pack already exists in
the object store when calling add_pack_to_midx().
This would ultimately lead to a cycle being created along the
'packed_git' struct's '->next' pointer. That is obviously bad, but it
has hard-to-debug downstream effects like saying a bitmap can't be
loaded for a pack because one already exists (for the same pack).
Signed-off-by: Taylor Blau <me@xxxxxxxxxxxx>
---
midx.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/midx.c b/midx.c
index a24c36968d..567cdf0fcf 100644
--- a/midx.c
+++ b/midx.c
@@ -908,8 +908,18 @@ static int write_midx_internal(const char *object_dir, struct multi_pack_index *
if (m)
ctx.m = m;
- else
- ctx.m = load_multi_pack_index(object_dir, 1);
+ else {
+ struct multi_pack_index *cur;
+
+ prepare_multi_pack_index_one(the_repository, object_dir, 1);
+
+ ctx.m = NULL;
+ for (cur = the_repository->objects->multi_pack_index; cur;
+ cur = cur->next) {
+ if (!strcmp(object_dir, cur->object_dir))
+ ctx.m = cur;
+ }
+ }
ctx.nr = 0;
ctx.alloc = ctx.m ? ctx.m->num_packs : 16;
--
2.31.1.163.ga65ce7f831
