Re: [PATCH v2 4/8] packfile: pass down repository to `odb_pack_name`

Earlier I mentioned that another helper could simplify many of these
sites a little. What I meant was this (on top of what's in your series):

diff --git a/builtin/fast-import.c b/builtin/fast-import.c
index 9056447bd0..976cb1d77b 100644
--- a/builtin/fast-import.c
+++ b/builtin/fast-import.c

@@ -806,19 +806,19 @@ static char *keep_pack(const char *curr_index_name)
 	struct strbuf name = STRBUF_INIT;
 	int keep_fd;

-	odb_pack_name(the_repository, &name, pack_data->hash, "keep");
+	pack_hashfile(pack_data, &name, "keep");
 	keep_fd = odb_pack_keep(name.buf);
 	if (keep_fd < 0)
 		die_errno("cannot create keep file");
 	write_or_die(keep_fd, keep_msg, strlen(keep_msg));
 	if (close(keep_fd))
 		die_errno("failed to write keep file");

-	odb_pack_name(the_repository, &name, pack_data->hash, "pack");
+	pack_hashfile(pack_data, &name, "pack");
 	if (finalize_object_file(pack_data->pack_name, name.buf))
 		die("cannot store pack file");

-	odb_pack_name(the_repository, &name, pack_data->hash, "idx");
+	pack_hashfile(pack_data, &name, "idx");
 	if (finalize_object_file(curr_index_name, name.buf))
 		die("cannot store index file");
 	free((void *)curr_index_name);

@@ -832,7 +832,7 @@ static void unkeep_all_packs(void)

 	for (k = 0; k < pack_id; k++) {
 		struct packed_git *p = all_packs[k];
-		odb_pack_name(p->repo, &name, p->hash, "keep");
+		pack_hashfile(p, &name, "keep");
 		unlink_or_warn(name.buf);
 	}
 	strbuf_release(&name);

diff --git a/builtin/pack-redundant.c b/builtin/pack-redundant.c
index 7d6c47ffd9..d3b5e7e112 100644
--- a/builtin/pack-redundant.c
+++ b/builtin/pack-redundant.c

@@ -690,7 +690,7 @@ int cmd_pack_redundant(int argc, const char **argv, const char *prefix UNUSED, s
 	pl = red = pack_list_difference(local_packs, min);
 	while (pl) {
 		printf("%s\n%s\n",
-		       odb_pack_name(repo, &idx_name, pl->pack->hash, "idx"),
+		       pack_hashfile(pl->pack, &idx_name, "idx"),
 		       pl->pack->pack_name);
 		pl = pl->next;

G 	}

diff --git a/packfile.c b/packfile.c
index cfbfcdc2b8..d81a62eb84 100644
--- a/packfile.c
+++ b/packfile.c

@@ -46,6 +46,11 @@ char *odb_pack_name(struct repository *repo, struct strbuf *buf,
 	return buf->buf;
 }

+char *pack_hashfile(struct packed_git *p, struct strbuf *out, const char *ext)
+{
+	return odb_pack_name(p->repo, out, p->hash, ext);
+}
+
 static unsigned int pack_used_ctr;
 static unsigned int pack_mmap_calls;
 static unsigned int peak_pack_open_windows;

diff --git a/packfile.h b/packfile.h
index 3409aef35d..43c19d7bba 100644
--- a/packfile.h
+++ b/packfile.h

@@ -32,6 +32,9 @@ struct pack_entry {
 char *odb_pack_name(struct repository *repo, struct strbuf *buf,
 		    const unsigned char *hash, const char *ext);

+/* Like odb_pack_name(), but pull repo and hash from existing packed_git. */
+char *pack_hashfile(struct packed_git *p, struct strbuf *out, const char *ext);
+
 /*
  * Return the basename of the packfile, omitting any containing directory
  * (e.g., "pack-1234abcd[...].pack").

While coming up with the name, though, I had some second thoughts. The
interface implies that its the way you should derive a pack-related
filename from a packed_git. But it really is mis-designed for that
purpose! The packed_git struct has "foo.pack" or similar in its
pack_name field, and the correct way to derive the .idx, .bitmap, .keep,
etc, is by string substitution. While we do tend to name packs
pack-$hash.pack, most of the code will happily work on
"some-arbitrary-name.pack". And that's why we have so few
odb_pack_name() calls in the first place.

IMHO the ones in fast-import should probably be doing that suffix
replacement instead (and probably we should have a decent helper to
facilitate that; you can grep for strip_suffix.*pack to see places that
could potentially use it).

All that said, I don't think it's worth derailing your series to deal
with that cleanup. That can come later if we want. And if we do that,
then the pack_hashfile() I suggested above would have no callers,
because it's the wrong approach.