On Sun, Jan 21, 2007 at 05:38:57PM -0800, Steven Grimm wrote:

quoted text
> >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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html