Re: git gc does not clean tmp_pack* files

From: Boomman <boomman37@gmail.com>
Date: Dec 28, 2024, 20:13 UTC
Message-ID: <CADMKT2-kK=CNp4aeL2JciugQdNWed62VRmkc-CTaUNxoMxZNwQ@mail.gmail.com>
In-Reply-To: <20241228194428.GB1535629@coredump.intra.peff.net>

Right, but you know the *intent* of why each pack was created, right? This is push, this is pull, this is gc. Clearly some of those are expected to not run in parallel in normal scenarios, like gc. I imagine there are more: fetch from a single remote, push to a single remote? Why not make their packs names contain an operation identifier that's supposed to be unique by default instead of a random string: tmp_fetch_myremote, tmp_push_myotherremote. This way you can reduce the number of trash from failed operations, since the same location is going to be overwritten each call, plus the folder contents will be much more comprehensible at a glance.

-Vitaly

On Sat, Dec 28, 2024 at 11:44 AM Jeff King <peff@peff.net> wrote:

Show 17 quoted lines

>
> On Fri, Dec 20, 2024 at 05:17:50PM -0800, Boomman wrote:
>
> > For me, two "git gc" on a same repo fail to run:
> > fatal: gc is already running on machine 'WIN-blah' pid 40304 (use
> > --force if not)
> >
> > If you're already colliding on this, then I don't see why you can't
> > use a normal looking name without a randomized string like
> > "tmp_garbagecollecting", so that each execution would at least
> > overwrite the same location. In this case --force could append _1
> > probably.
>
> git-gc is not the only thing that writes packs. There might be
> simultaneous packs written by incoming pushes or fetches, for example.
>
> -Peff