Re: [PATCH] prune: --expire=time
- From
Steven Grimm <koreth@midwinter.com>
- Date
- Jan 22, 2007, 01:38 UTC
- Message-ID
- <45B415B1.30407@midwinter.com>
- In-Reply-To
- <20070121220114.GA24729@coredump.intra.peff.net>
Jeff King wrote:
Show 11 quoted lines
> That's not sufficient either. You might not _have_ the young objects > yet, think the blob is dangling, and delete it. Meanwhile, the tree that > references it arrives. IOW, > 1. blob B arrives, but already exists > 2. prune deletes unreference and old blob B > 3. tree T arrives, referencing blob B > I think this might be safe if you add objects in a top-down way (i.e., T > before B). However, that doesn't make sense for the commit operation, in > which you add blobs (with git-add), and then eventually construct a > tree. >
Shouldn't the repository be locked against operations like prune while a commit is in progress anyway? That seems like it's pretty prudent and reasonable to me -- doing otherwise is just asking for a zillion little race conditions. Prune should be a rare enough operation that having it abort (or better, block) while a commit is going on wouldn't be a big problem, I'd think.
-Steve