Jeff King <peff@peff.net> writes:

quoted text
> 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?

This case does not need any locking, as blobs reachable from
index are considered as "reachable" for the purpose of pruning.

-
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