Re: fetching packs and storing them as packs

[Nicolas Pitre <nico@cam.org>]

On Thu, 26 Oct 2006, Shawn Pearce wrote:

> Nicolas Pitre <nico@cam.org> wrote:
> > 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 is an issue for "central" repositories that people push into
> and which might be getting repacked according to a cronjob.
> 
> Unfortunately I don't have a solution.  I tried to come up with
> one but didn't.  :-)

Just continue to explode received packs into loose objects then.  It is 
that simple.  I said there were advantages and inconvenients to both 
methods. This one is a nice example.

I won't repack from a cron job, so I don't expect to run a repack and a 
fetch at the same time on my private repositories.  I therefore don't 
care about that race and so is the case for the vast majority of users.