Re: git-index-pack really does suck..

From: Jeff King <peff@peff.net>
Date: Apr 3, 2007, 22:10 UTC
Message-ID: <20070403221006.GA17948@coredump.intra.peff.net>
In-Reply-To: <20070403215342.GL27706@spearce.org>

On Tue, Apr 03, 2007 at 05:53:42PM -0400, Shawn O. Pearce wrote:

Show 8 quoted lines

> > If that is the only reason we have these reprepare_packed_git()
> > sprinkled all over in sha1_file.c (by 637cdd9d), perhaps we
> > should rethink that.  Is there a cheap way to trigger these
> > rescanning only when a prune-packed is in progress, I wonder...
> 
> Yea, it is the only reason.  So... if we could have some
> magic to trigger that, it would be good.  I just don't
> know what magic that would be.

It doesn't have to be in progress; it might have started and completed between pack-scanning and object lookup. Something like:

  1. start git-repack -a -d
  2. start git-rev-list, scan for packs
  3. repack moves finished pack into place, starts git-prune-packed
  4. git-prune-pack completes
  5. git-rev-list looks up object

So you would need to have some sort of incremented counter that says "there's a new pack available."

Perhaps instead of rescanning unconditionally, it should simply stat() the pack directory and look for a change? That should be much cheaper.

-Jeff