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. 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