On Mon, Jun 11, 2012 at 01:04:07PM -0400, Nicolas Pitre wrote: > 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. Nope, the HEAD reflog dates back to bd104db (enable separate reflog for HEAD, 2007-01-26), whereas the discussion leading to gc.pruneExpire was in 2008. See this sub-thread for the discussion on the time limit: http://thread.gmane.org/gmane.comp.version-control.git/76899/focus=76943 The interesting points from that thread are: 1. You might care about object prune times if your session is interrupted. So imagine you are working on something, do not commit, go home for the weekend, and then come back. I think we are OK with most in-progress operations, because any blobs added to the index will of course be considered reachable and not pruned. What would hurt most is that you could do: $ hack hack hack $ git add foo $ hack hack hack $ git add foo $ hack hack hack [oops! I realized I really wanted the initial version of foo!] $ git fsck --lost-found If your session is interrupted during the third "hack hack hack" bit, a short prune might lose the initial version. Of course, that's _if_ a gc is run in the middle. So I find it possible, but somewhat unlikely. 2. If a branch is deleted, all of its reflogs go away immediately. A short expiration time would mean that the objects will probably go away at the next "gc". In many cases, you will be saved by the HEAD reflog, which stays around until the real expiration is reached. But not always (e.g., server-side reflogs). I'd much rather address this in the general case by saving deleted-branch reflogs, though I know you and I have disagreed on that in the past. One issue not brought up in that thread is that of bare repositories, which do not have reflogs enabled by default. In that case, the 2-week prune window is really doing something. I really wonder if there is a good reason not to turn on reflogs for all repositories, bare included. We have them on for all of the server-side repositories at github, and they have been invaluable for resolving many support tickets from people who forced a push without realizing what they were doing. -Peff -- 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