On Tue, Apr 03, 2007 at 05:53:42PM -0400, Shawn O. Pearce wrote: > > 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 - 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