Re: fetching packs and storing them as packs

[Nicolas Pitre <nico@cam.org>]

On Fri, 27 Oct 2006, Eran Tromer wrote:

> Hi,
> 
> On 2006-10-26 17:08, Nicolas Pitre wrote:
> > On Thu, 26 Oct 2006, Eran Tromer wrote:
> >> This creates a race condition w.r.t. "git repack -a -d", similar to the
> >> existing race condition between "git fetch --keep" and
> >> "git repack -a -d". There's a point in time where the new pack is stored
> >> but not yet referenced, and if "git repack -a -d" runs at that point it
> >> will eradicate the pack. When the heads are finally updated, you get a
> >> corrupted repository.
> > 
> > And how is it different from receiving a pack through git-unpack-objects 
> > where lots of loose objects are created, and git-repack -a -d removing 
> > those unconnected loose objects before the heads are updated?
> 
> git-repack -a -d does not touch unconnected loose objects.
> It removes only unconnected packed objects.

Right.

> Only git-prune removes unconnected loose objects, and that's documented
> as unsafe.

Well, the race does exist.  Don't do repack -a -d at the same time then.

This race should be adressed somehow if it is really a problem.  Now 
that I've used index-pack in place of unpack-objects for a while, I 
don't think I'll want to go back.  It is simply faster to fetch, faster 
to checkout, faster to repack, wastes less disk space, etc.