On Sun, Jan 21, 2007 at 05:38:57PM -0800, Steven Grimm wrote: > >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. I was a bit loose with my phrase 'commit operation'. What I really mean is: $ git add file ;# (1) $ hack hack hack ;# (2) $ git commit ;# (3) After step (1), you have a blob in your db. If you already had that blob, then you have the old blob. You don't get the updated tree and commit until step (3). Step (2) can be hours or days. Do you really want to lock the repository that long? Potentially we could 'touch' the blob in step (1) to update its timestamp. But if we update timestamps for things like commit, then that might mean 'touch'ing tens of thousands of objects for a commit which _should_ only require making a few objects. -Peff - 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