On Thu, 26 Oct 2006, Shawn Pearce wrote: > Nicolas Pitre <nico@xxxxxxx> 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. Nicolas - 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