Re: fetching packs and storing them as packs
- From
Shawn Pearce <spearce@spearce.org>
- Date
- Oct 27, 2006, 01:42 UTC
- Message-ID
- <20061027014229.GA28407@spearce.org>
- In-Reply-To
- <Pine.LNX.4.64.0610262038320.11384@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
Show 26 quoted lines
> 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. :-)