]> git.ipfire.org Git - thirdparty/git.git/commit
builtin/gc: remove global `repack` variable
authorPatrick Steinhardt <ps@pks.im>
Fri, 24 Oct 2025 06:57:14 +0000 (08:57 +0200)
committerJunio C Hamano <gitster@pobox.com>
Fri, 24 Oct 2025 20:42:42 +0000 (13:42 -0700)
commit0ea94b023a64d1341a11252954bb7ce37dd3d922
treeb3533b60161176243fd2816ec54a78ee54925f02
parent8bca1c5d5993d1dcb234f37031a9687ae20bdc22
builtin/gc: remove global `repack` variable

The global `repack` variable is used to store all command line arguments
that we eventually want to pass to git-repack(1). It is being appended
to from multiple different functions, which makes it hard to follow the
logic. Besides being hard to follow, it also makes it unnecessarily hard
to reuse this infrastructure in new code.

Refactor the code so that we store this variable on the stack and pass
a pointer to it around as needed. This is done so that we can reuse
`add_repack_all_options()` in a subsequent commit.

The refactoring itself is straight-forward. One function that deserves
attention though is `need_to_gc()`: this function determines whether or
not we need to execute garbage collection for `git gc --auto`, but also
for `git maintenance run --auto`. But besides figuring out whether we
have to perform GC, the function also sets up the `repack` arguments.

For `git gc --auto` it's trivial to adapt, as we already have the
on-stack variable at our fingertips. But for the maintenance condition
it's less obvious what to do.

As it turns out, we can just use another temporary variable there that
we then immediately discard. If we need to perform GC we execute a child
git-gc(1) process to repack objects for us, and that process will have
to recompute the arguments anyway.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Acked-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/gc.c