Re: git gc does not clean tmp_pack* files

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 19, 2024, 11:17 UTC
Message-ID: <xmqqmsgrncr6.fsf@gitster.g>
In-Reply-To: <CADMKT28cZcdW8UJ59vZHoMa0WEbyAccx4A10-jk3MiBkhZLxEg@mail.gmail.com>

Boomman <boomman37@gmail.com> 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.