Subject: Re: git gc does not clean tmp_pack* files

From: Junio C Hamano <[email-masked]>
Date: Thu, 19 Dec 2024 03:17:01 -0800

Boomman <[email-masked]> writes:

> Yes, if the behavior in case of running out of disk space is to just
> leave the malformed file there, it stands to reason that cleaning up
> those malformed files should be the first operation to do for gc.

It is misleading to call them malformed, isn't it?  When a Git
process creates a packfile (or loose object file for that matter),
they are written under these tmp_* names.  When the processes die
without finalizing these (either removing or renaming into their
final names), they are left behind, and it would be better if we can
remove it _before_ another process wants to consume more disk space.

But the issue is how you tell which one of these "malformed" files
are still being written and will be finalized, and which ones are
leftover ones.  You want to remove the latter without molesting the
former.  And you want to do so in a portable way, possibly even
across the network file systems.

I guess, as Peff alluded to, we could do at the beginning of "gc" to
prune only these "possibly in progress, possibly leftover" files
that are too old, repack the clearly "finalized" ones, and then
prune again, this time including the "finalized" ones that are no
longer in use, which would help the creation of new packfiles from
being blocked by these leftover files that are hoarding disk quota.