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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
