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

[Nicolas Pitre <nico@cam.org>]

On Wed, 6 Feb 2008, David Tweed wrote:

> 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