Re: [PATCH] Make git prune remove temporary packs that look like write failures

From: Nicolas Pitre <nico@cam.org>
Date: Feb 6, 2008, 19:31 UTC
Message-ID: <alpine.LFD.1.00.0802061420510.2732@xanadu.home>
In-Reply-To: <e1dab3980802061110p2c1dad1ep8a46eeda93839bb9@mail.gmail.com>

On Wed, 6 Feb 2008, David Tweed wrote:

Show 6 quoted lines

> I guess the -n ought to be honoured. However, unless I'm missing
> something, the case of expiring objects is different. The primary
> reason is that objects can get orphaned by "semantic" decisions
> (delete this branch, rewind, etc) so they contain valid content that
> you might want to later rescue (using low-level command like git cat
> if necessary).

You can also get loose unconnected objects when fetching and the number of objects is lower than the transfer.unpackLimit value.

> In contrast, the only way to get a temporary pack when
> the repository is quiescent is resulting from a _write error_ and thus
> is a corrupt entity which it would take a great deal of work to
> extract any valid data from.

Or when a fetch is in progress, just like the case above, but with the number of objects greater than transfer.unpackLimit.

This is uncommon to have a prune occurring at the same time as a fetch, but the --expire argument is there if for example you do a prune from a cron job but still want to be safe by giving a grace period to garbage files which might not be so after all.

Nicolas