@@ -737,7 +737,7 @@ void bitmap_writer_select_commits(struct bitmap_writer *writer,
stop_progress(&writer->progress);
- select_pseudo_merges(writer, indexed_commits, indexed_commits_nr);
+ select_pseudo_merges(writer);
}
@@ -425,8 +425,7 @@ static void sort_pseudo_merge_matches(struct pseudo_merge_matches *matches)
QSORT(matches->unstable, matches->unstable_nr, commit_date_cmp);
}
-void select_pseudo_merges(struct bitmap_writer *writer,
- struct commit **commits, size_t commits_nr)
+void select_pseudo_merges(struct bitmap_writer *writer)
{
struct progress *progress = NULL;
uint32_t i;
@@ -95,8 +95,7 @@ struct pseudo_merge_commit_idx {
*
* Optionally shows a progress meter.
*/
-void select_pseudo_merges(struct bitmap_writer *writer,
- struct commit **commits, size_t commits_nr);
+void select_pseudo_merges(struct bitmap_writer *writer);
/*
* Represents a serialized view of a file containing pseudo-merge(s)
We take the array of indexed_commits (and its length), but there's no need. The selection is based on ref reachability, not the linearized set of commits we're packing. Signed-off-by: Jeff King <peff@peff.net> --- A careful reader may wonder whether we ought to be using the set of commits to limit what we're willing to select (since we can't make a bitmap for a commit that isn't in our index). And this is indeed a problem, but the solution doesn't involve using indexed_commits. It should be fixed in this series: https://lore.kernel.org/git/c9a64b1d2a9d6b3fe1f5fb0a7303e043114fcd8f.1723743050.git.me@ttaylorr.com/ pack-bitmap-write.c | 2 +- pseudo-merge.c | 3 +-- pseudo-merge.h | 3 +-- 3 files changed, 3 insertions(+), 5 deletions(-)