Re: Keeping unreachable objects in a separate pack instead of loose?

From: Jeff King <peff@peff.net>
Date: Jun 11, 2012, 17:46 UTC
Message-ID: <20120611174628.GA20134@sigill.intra.peff.net>
In-Reply-To: <alpine.LFD.2.02.1206111249270.23555@xanadu.home>

On Mon, Jun 11, 2012 at 01:04:07PM -0400, Nicolas Pitre wrote:

Show 7 quoted lines

> 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