On Mon, 11 Jun 2012, Jeff King wrote: > As a workaround, it might be worth lowering the default pruneExpire from > 2 weeks to 1 day or something. It is really about creating safety for > operations in progress (e.g., you write the object, and then are _about_ > to add it to the index or update a ref when it gets pruned). I think the > 2 weeks number was pulled out of a hat as "absurdly long for an > operation to take", and was never revisited because nobody cared or > complained. Absolutely. I think this should even be considered a "fix" to lower this value not a "workaround". IIRC, the 2 weeks number was instored when there wasn't any reflog on HEAD and the only way to salvage lost commits was to use 'git fsck --lost-found'. These days, this is used only as a safety measure because there is always a tiny window during which objects are dangling before they're finally all referenced as you say. But someone would have to work hard to hit that race even if the delay was only 30 seconds. So realistically this could even be set to 1 hour. 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